Example: Product Discovery Workflow
Collaborate before deliverables exist. Iterate before high fidelity. Include an engineer at every step.
There are many ways to accomplish Product Discovery.
In recent interviews with engineers, it became clear that Product teams are taking short cuts and excluding engineering.
This is a simplified guide to the collaborative and iterative nature of developing ideas with engineers in a way that saves total time to success.
Iterate in design with the advice of an engineer rather than iterating in engineering with the advice of a designer.
Learn about the benefits to this form of Product Discovery in this article “Stop protecting your engineers time.”
1. Start with working sessions. Develop context. No need for deliverables.
Too often, Product Managers try to put together a tight and tidy package of information for their colleagues. They think that by doing more work upfront that their team will appreciate the effort.
Or they may want to steer almost all of the direction of the project so they work alone in advance of everyone else to push ahead with their personal vision.
This do it alone style does not guarantee success. It excludes the technology-based innovation that comes from engineer involvement. It excludes serious consideration of customer needs.
And it relegates Designers and others on the team to executing the PM’s vision rather than being a part of creating the solution. This leads to fewer perspectives being incorporated and less buy-in when it comes time to execute to a deadline.
Start with collaborative working sessions and present the homework that’s been done to date. Make sure to constrain the discussion by providing clear guidance on the following. Then you’ll have a great beginning to your Product Discovery process.
Ingredients to begin a successful Product Discovery cycle:
Business objective
Business metric goal
Target customer
Customer problem or opportunity
Any other homework or relevant data
All of your relevant colleagues. See “Example: Product Discovery Team”
Quotes from Engineers who have participated in Product Discovery:
“I like each product build cycle to start with a kickoff so I can understand the context on the problem we are trying to solve.”
“I prefer a collaborative session first because I think it’s important to understand what we’re building and get people bought in.”
“Collaborative meetings create a good idea of what is being built and why and what the metrics of success are in the PMs mind.”
2. Involve an engineer in solutioning
Again, Product Managers often create solutions on their own and then pass them to their Designer for beautification and then ask an Engineer for an estimate.
Don’t do this.
Solutioning is a group effort. Product Managers and/or Designers can lead working sessions to create solutions that incorporate more perspectives and generate a shared understanding within the team.
In the beginning, working collaboratively can be slow. Everyone has an opinion or perhaps individuals in the group aren’t participating since they don’t have the previous experience of helping to create solutions. Or their feedback isn’t relevant since they don’t know the subject matter as well as the PM.
As Product teams work in collaborative sessions, each individual gets smarter about the subject matter at hand. Each individual gets better at envisioning an amazing user experience that will solve a problem or unlock an opportunity.
By the third Discovery cycle, each individual on my teams is better at ideating, sketching, envisioning a user experience and contributing constructively to a group.
To facilitate effective Product Discovery, Product professionals can consult the Sprint book by the Google Ventures folks. Or they can hire an experienced coach like me to help them through their first few attempts.
Once you’ve learned to incorporate your colleagues opinions and ideas, you’ll feel more like a group. And you’ll operate more efficiently since you’ve developed awareness about the solution due to everyone being present when decisions were made and when background material for the decisions was collected.
Quote from an Engineer who has participated in Product Discovery:
“I like to be involved in the brainstorming process on how to solve the problem and what would be technically feasible in our estimated timeframe. Let engineers help come up with the product solution and give input into design, especially when you are working with front-end engineers.”
3. Iterate first in low fidelity design
Most teams I work with want to go straight to a final solution and send the designer off on their own to synthesize whatever information the group has been collecting, creating and discussing.
This is too fast.
When 5 people leave a room, usually there are 5 different interpretations of what happened.
By working in low fidelity which is faster, the designer can reflect to the group sooner what they think happened while everything is fresh in everyone’s mind.
This quick turnaround lowers the risk of investing time and energy into pixel perfect designs that aren’t what everybody thought they agreed to.
By iterating quickly, the designer doesn’t risk wasting time and includes their team along the way.
Doing big reveals of finished work is too risky.
In addition, Designers should be creating at least 2 different solutions in the beginning to push their team to explore potentially more valuable solutions. It’s so much easier and cheaper to experiment and innovate in design. Teams don’t take advantage of this ability enough.
Quotes from Engineers who have participated in Product Discovery:
“A lot of the work is getting the iteration speed up. Making sure the designer has time to do a couple of revisions (since it’s so much cheaper).”
“Low fidelity mockups / wireframes help me get into the context of the product change and helps the entire team to hash out a few things before we have invested more time into the deeper design and product decisions”
“Then I like to see the designers go off and create basic mockups and wireframes. At that point I like to discuss what they came up with, and fine tune the ideas so they can go off and make more detailed mockups based on our design system principles.”
“I like wireframes more than mockups because the focus at this stage should be on thinking through the flows and dependencies, less about look and feel.”
4. Create a high fidelity deliverable and test with target customers
Many teams are delivering high fidelity clickable prototypes to their engineering teams and executives as final deliverables. These deliverables are also perfect for testing value with customers: business or consumer.
For API development, teams should create API docs with endpoints and descriptions of inputs and outputs.
In reporting and analytics, teams should be creating fake reports with real data to get a reaction from the user. To create a report or analysis, teams have to first collect new data, clean existing data, set up a new data store and create a specialized representation of the data. So iterating in software for analytics teams takes much more time than other types of products. By doing Product Discovery with a realistic looking report created only by a designer, the team can understand whether a given set of data is valued by the customer. Teams will need the help of data analyst to provide realistic data to the designer to create these fake-realistic reports.
High fidelity deliverables can be any of the following:
High fidelity clickable prototypes for user interactions
Fully written API docs for APIs
Detailed flow diagrams for data engineering
A report or graphical analysis with realistic data
5. Iterate, Validate or Discard
The core of Product Discovery is understanding that not all ideas should be built and launched.
Product Discovery seeks to expose your best thinking to real customers in realistic ways to get authentic reactions.
Great Product teams create an expansive set of ideas and solutions that purposely explore a wide solution space. They know that most ideas will fail so they play the odds. They create multiple solutions and only build the ones that customers find valuable.
These Product teams use Discovery to weed out the “meh” solutions and focus their efforts on the “aha!” solutions (as judged by customers).
Send validated ideas to engineering.
Iterate ideas with potential.
Discard ideas that are not valuable to users.
Jim knows how to build successful teams and products from scratch.
He co-founded PowerReviews, a B2B2C product reviews SaaS platform, that had an exit in 2012 for $168 million at a 13x multiple. In the early days of the web, he product managed and architected one of the original ecommerce sites that had a $66 million IPO in 1999, online sporting goods retailer Fogdog.com.
For his Product teams, he’s created a curriculum and training program that pulls from his 20+ years of experience and the best minds in Product Management. In addition, he relies on his software engineering background and experience to bridge the gap between their Product and Engineering teams. He graduated from Stanford University with a degree in Computer Science.
Jim is based in San Francisco and works with clients from 2 to 20,000 employees in a variety of industries and business models. Previous clients include VSP Global, PagerDuty, Dictionary.com, and Hallmark. He’s also worked with startups in machine learning, API development, computer vision, payments and digital health.
