Delivering New Products for Fun and Profit, Part 2

Discovery

In Part 1, we gave an overview of the process:

• Discovery, where we identify the customer problem and set the vision.
• Pre-work to ignite understanding, where the team begins to digest the market and technical information to understand the problem.
• The Kickoff, where we decide what is in and out of scope and identify the minimum viable system (aka, the steel thread).
• Innovation & Experimentation, where we answer our biggest technical questions and test ideas with customers.
• Customer Advisory, where we engage with customers to guide our direction. (This customer advisory group is usually set up at the same time as Innovation & Experimentation.)
• Iteration, where we build our product until it is “good enough”, continuously learning, making tough decisions, and testing with customers.
• Delivery, where we launch our product successfully.

In this post, I’ll talk more about our expectations for the “Discovery” phase of work.

Discovery is primarily in the realm of Product Management or Product Development. It is usually an ongoing process, and many projects and ideas never get out of discovery. To exit discovery, we need to take in data from a variety of data sources and output a product vision that, when built and sold, will generate revenue for the firm. Once this vision is in an acceptable state we can go to the next phase of work (which can sometimes be done concurrently), which is Pre-Work.

Discovery is our opportunity to get alignment from our stakeholders, get laser focused on the real value, and make critical tradeoffs before work even begins — what we’re not doing is usually just as important to decide as what we are doing.

The data used to synthesize our vision can come from any number of a variety of sources:

• Surveys
• Industry research, like from Gartner
• Customer interviews or, better yet, onsite research
• Sales feedback
• Market and competitive analysis
• Exercises like SWOT analysis
• Executive leadership feedback

There are some traps to effective discovery. One trap is to conflate the “what” and the “how” when generating your vision. When your vision describes data formats, includes architecture diagrams, or UX mockups you have fallen into the “what vs. how” trap. We want to describe the overall value proposition not the technical details.

One of my many theories is that the distance between our vision, the technical details, and the actual customer experience is where innovation happens — where we challenge our teams to develop sophisticated and innovative solutions to deliver on our vision.

Another trap is what I call “going off to the mountain.” This is where you are building your vision in isolation. Much like how we want to test our minimum viable product (MVP) with customers, we should be testing our vision with stakeholders, sales staff, even customers. The more aligned we can get before we start work the better our overall outcome will become.

Going to the mountain can also lead you to set your vision too far into the future and become unachievable. Sometimes this might be desirable — when we need to cause organizational disruption, for example.

Stakeholder alignment, whether that is just your boss, the executive team, or the board of directors, is a key function of the vision. Without this alignment at the inception of your project you run a much higher risk of encountering additional pressure to deliver something different, faster, and usually bigger after you’ve already started work. In my opinion, this is the primary reason that projects churn partway through development, which is extremely costly. When engaging stakeholders on a draft of your vision, remember that you are listening for their concerns so that you can address them and drive alignment and understanding.

So what makes a good vision? Here’s some tests for a decent vision with some made up examples for FreshHomeDelivery, a grocery delivery service.

• A vision clearly states the problem the customer is experiencing. “Before, shopping for the ingredients for meals was slow and time consuming. You needed to identify recipes, make a list, find the right store, and shop. After a long day at work this significantly delayed the start of dinner preparation.”
• A vision should differentiate. “Until now, other meal services lock you in to certain days and don’t work around your schedule for delivery.”
• A vision should describe the value that we unlock. “Now, with FreshHomeDelivery, ingredients for pre-planned meals are delivered to your door fresh and ready to use. No shopping is required, the household can coordinate and manage their choices, and dinner preparation can begin immediately.”
• A vision should show the business model. “Local markets are excited to get FreshHomeDelivery’s business. ‘With FreshHomeDelivery we’ve seen an increase in sales with no effort since groceries are handpicked from local stores,’ said Timothy T, a store manager at Safersons Markets. ‘I’ve been able to spend more time with my family, and the flat charge fits my budget and is well worth the time and effort saved,’ said Suzy Q, who uses FreshHomeDelivery an average of three times a week.” *
• A vision should provide a litmus test for work we discover: When we discover things we could do, the vision should provide the test if we should proceed with the work now or delay it. To help with this we usually add a FAQ to our vision to address corner cases or answer specifically what our vision is not.

* Yes, these quotes are made up. Yes, we do add fake quotes for illustration.

There are a variety of great techniques that are already out there to help guide your discovery results. Amazon’s Working Backwards is one of our favorites: You build a “fake” press release (similar to above examples) as the vision. It cleanly separates the “what” from the “how” and can be very clarifying in a single page description.

Another option is a product or project brief, which usually includes market data, competitive analysis and a proposal for the shape of the product. In my opinion, these can more easily fall into the “what vs. how” trap, but they also include more market background than the Working Backwards framework.

Now that we’ve aligned on a vision, we can exit discovery and begin pre-work, which I’ll cover in my next post.