--- title: "When Will It Be Done?" source: "/writing/when-will-it-be-done/" --- Article # When Will It Be Done? ## How Bad Questions Give You Bad Software (And What To Ask Instead) Collin Flynn April 1, 2019 Businesses plan budgets and manage deliveries. Any project must have a projected cost and timeline. Is software somehow exempt? > How Much Will It Cost and When Will It Be Done? Similar to asking "What is north of the North Pole?", you can expect nonsense for an answer. As a developer, I see this mistake repeated routinely. Your software is not a vehicle to transport your product. It _is_ your product. Creating _useful_ products is a process of discovery and adaptation. Misapplying bad questions to a software project will prevent you from capitalizing on those discoveries while you waste time and money on first-draft features. Perhaps worse, deadline fixation can incentivize toxic **internal politics** instead of unity around a mission. More on that later. Regardless, everyone has a budget. What should a stakeholder ask if not for a timeline and cost? To demonstrate by way of contrast, I'll start with the kind of project where cost and timeline are reasonable first-class questions: building a house. After, I'll show a real world example of a software project that succeeded by asking the right questions, and how to apply those questions in software projects generally. ## Build Me A House Imagine you work at a development company (construction development, not software development) managing many teams. The boss stops you in the hall. "I have a project for you. I have allocated funds and I'd like you to start as soon as possible. I need you to build a house." You reach for your notes as you start to ask a few questions -- but the boss interrupts, "No no, don't ask me to list the features or give implementation details -- I know it needs a front door, but houses are complex and your teams have the expertise needed to make good design and development choices. Work within the budget and _give me the most house I can get_ for the money." With your new high-level mission, you consult your teams and draft a set of features: - Front Door - Plumbing - Heating - Electricity - Ball Pit Since you like to plan out a project timeline, you visit each team and get estimates, compile them into one coordinated calendar, and let the boss know when to expect completion. There might be little delays: maybe the front door you wanted is on back-order, or you find out the ball pit needs a slide. How could you forget the slide? However, while construction is underway you're unlikely to uncover a tantalizing opportunity to build a water park instead. While each feature of the house has lots of technical details to be solved, the end product is broadly understood ahead of time. And even allowing for plenty of creativity, the feature set is unlikely to be overhauled. Upon the delivery date you wouldn't expect to see the starting list of features fully replaced by these: - Aviary - Full Time Barista - A Big Red Phone Booth What would have to change about your understanding of houses (or the world, even) to lead to that new feature list? But creating digital products is fundamentally different -- you _can_ discover new information that changes everything, including your first-draft features. By asking good questions in the software development process, you can start building a house but end up delivering a water park. We'll take a look at how that plays out with a project analogous to the house example, but first see a real-world digital product that made such a transformation. ## Software Is Not A House Remember _Burbn_? No? Maybe you know it by its relaunch name, _Instagram_. Before _Instagram_ changed the way people share photos, it was positioned in the market as a _Foursquare_ competitor. Don't remember that one either? Foursquare's beginnings on iOS _Foursquare_ (which still exists in a different form) was an early entrant to the mobile app space, based around the idea of finding and sharing local treasures like restaurants, meetups, and events. It rewarded users with badges and accolades for "checking in" to these places regularly, and crowned "Superuser" status for contributing high quality reviews and recommendations. It had a to-do list, friending, ratings, and branded pages for businesses. Many of those features eventually found their way into other products like _Yelp_, _Meetup,_ and _Facebook._ Having them all in one product was confusing in the nascent smartphone market, and _Foursquare_ had a hard time crafting an elevator pitch. With a correspondingly bloated feature set, _Burbn_ was more of the same. But creators Kevin Systrom and Mike Krieger noticed a pattern: _Burbn_ users were in love with a below-the-fold and almost-hidden feature that allowed them to share pictures in real time. The smartphone camera played a part -- it used to be that the camera and the means of uploading photos were separated by a USB cable. Sharing photos on Burbn Take note, _Burbn_ started with an event feed, "moves", event planning, and achievements (gamification was all the rage). If pivoting away from these features appears obvious, it is only in retrospect: > And the hardest part of going from Burbn to Instagram was actually realizing that we had to do something new. And making that decision was one of the hardest parts of my entrepreneurial career. > > -- Instagram Co-Founder Kevin Systrom _Instagram'_s subsequent exponential growth is impressive, but not the reason I bring it up. Any growth whatsoever would've been improbable if _Burbn_ had been treated like a canonical list of required features rather than an exploration of uncharted territory. ## Build Me A Software Imagine you quit your previous job building houses. You're now overseeing software development at **Computer Parts Emporium**, a small but growing vendor of PC parts. _(While this company is fictional, the approach that follows will translate directly into building real digital products.)_ The boss stops you in the hall. "I have a project for you. I have allocated funds and I'd like you to start as soon as possible. Build us a better website." You understand that the online purchase experience at **Computer Parts Emporium** is poor, and you need to make improvements. You reach for your notes and start to ask a few questions -- but the boss interrupts -- "No no, don't ask me to list all the features or give implementation details -- software is complex and your team has all the expertise needed to make good design and development choices. Just work within the budget and give me the best website I can get for the money." Knowing about the history of _Instagram_, you understand that building software is not like building a house. You can't declare all the features up front and expect to create a _useful_ product. You have to start with reasoned guesses but seek to gather as much feedback as soon as possible, being ready to pivot based on the best information at the time. To begin, you note the competitive advantages and weaknesses of Computer Parts Emporium: Advantages: - You have better customer service than competitors Weaknesses: - Customers have a hard time browsing your product catalog To accentuate your advantages and improve on weaknesses, you visit with your teams and draft a list of preliminary features: Features: - **Real-Time Online Chat** with a customer service rep, to emphasize what customers already love. - **Product Suggestions** based on purchase history, to help customers browse your catalog. - **Wishlist/Favorites** to help customers plan their purchases. Should you now ask your teams to estimate how long it would take to support these features in their entirety, and set a distant calendar date for completion? **No.** These are sensible choices but they have to prove their value. You are better served by asking for the shortest possible time it would take to answer the first set of unknowns in front of them. Everything from the technical plumbing (_is there a chat client that works well cross-platform?_) to early design prototypes will raise questions that can only be answered by validating against the product vision. You'll need to test experimental features with end users, dog-food internal builds, and compile analytics. It is highly _unlikely_ that your starting feature set perfectly captures value without that data. Each infusion of information comes on the scale of _micro-deadlines_: days, not weeks or months. Engineering and design will step incrementally towards targeted features while reserving the right to pivot to better alternatives. As the **Computer Parts Emporium** project rolls on, new information prompts reimagining the first-draft features: ### Your engineers discover that product recommendations are difficult You have a lot of purchase history data to work with, but in your niche market (computer parts) they don't reveal future preferences. There is more your engineering team can do to improve suggestions, but they estimate the effort is high. Still, you know customers want a better way to browse and discover products. You notice that these PC enthusiasts like to link products and discuss builds with each other as a means of discovery, but your current linking behavior isn't consistent across iOS, Android, and Web. You abandon automated suggestions and pivot to cross-platform **universal links**. These links come with analytics that tell you which products are trending from day-to-day. This data may fuel new experimental features or sales later on. ### When customers need help, they prefer to call Your service reps report that they keep getting the same few questions over and over again in Online Chat. You take the most common questions and generate **FAQs** on various product pages, then remove the real-time chat. Your service reps have more time to handle the bigger problems, and customer satisfaction goes up. ### Shoppers want to share their PC part lists with each other The **Wishlist** wasn't a hit when it was tested with a small group of real shoppers, but it was close. Enthusiasts like to discuss and share their orders before they buy, so you decide to augment the previous **universal links** to support lists of products. This doesn't require as much engineering work as a wishlist would, and it is more useful. Look back at where the Computer Parts Emporium product started, and the changes it made: - Real-Time Online Chat → FAQs on product pages - Product Suggestions → Cross Platform Universal Links - Wishlist/Favorites → Linkable PC part lists Is it _done_ now? Does the concept of _done_ even make sense when this software is a continuous relationship with your customers? Further, do you think discovery and adaptation are over? If Computer Parts Emporium had set out to build their first-draft features, they might've been able to guess a distant release date. At best they'd deliver something out of touch that is hard to change: bad recommendations, unused wishlists, and missed opportunities for sales growth. Worst of all, there may be unintended consequences for company culture that I alluded to in the introduction. ## The Culture Cost Of Deadline Fixation There is another insidious consequence of deadline fixation. Suppose you're overseeing a software project, and your engineers discover the core feature hinges on refactoring an old legacy system. The initial project deadline is suddenly infeasible. Would you abandon everything that makes the product _valuable_ so you can deliver something _on time_? What if your yearly bonus depends on it? Further, suppose the team tasked with the refactoring isn't too happy about it, finding the work unpleasant. Could they use your deadline fixation as a lever against you? > "We could do it, but it would risk on-time delivery." What about this one: How many times have you seen a team completely reject the idea of working with another team in the same company, claiming it would push out their projections and jeopardize their deliveries, even though the _product vision_ demands a holistic solution from both teams? This is deadline fixation coming from all sides (with a splash of poor leadership). The real world already presents enough problems without us pitting internal teams against one another. Is your priority a deadline, or a product? A product achieves value by continuously folding in new insights over time. These insights arrive through design prototypes, active user testing, [dog-fooding](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) , beta releases, and ongoing analytics. Embedded in the question "_how long will it take?_" is the assumption that you already have all the insights up-front. Embedded in the question "_how much will it cost?_" is the assumption that digital products are built once like a construction project. Asking these questions at the start of a project can irreversibly lock the assumptions into the end result via deadline fixation, deteriorating the relationship with your customers, preventing adaptation to market conditions, and missing the biggest opportunities for growth. _Collin helps companies build digital products -- not projects -- with_ [_Livefront_](https://www.livefront.com) _._ - Collin Flynn Principal Software Engineer Collin Flynn ### Tags [Digital Engineering](/insights/all/?topic=digital-engineering) [Mobile Apps](/insights/all/?topic=mobile-apps) ### Share - Copied ## View these next. [See all](/insights/all/?type=writing) - [ Article All eyes on me Ben Wood ](/writing/all-eyes-on-me/) - [ Article What Does the Release of iOS 18 Mean for the Digital Front Door? Diana Flotten ](/writing/what-does-the-release-of-ios-18-mean-for-the-digital-front-door/) - [ Article Rethinking the Product Roadmap: Bring Back the Utility and Practicality Jack Cunningham ](/writing/rethinking-the-product-roadmap-bring-back-the-utility-and-practicality/)