The Age of Product Discovery: Part II
Continued from The Age of Product Discovery Part I
So far we’ve been discussing how the tech industry has long excelled at optimizing how software gets developed, but tools and frameworks for deciding what products and features to build have been slower to emerge.
That’s a problem, because optimizing the how can help us iterate faster, but only by shipping production-ready software. There must be a better way to discover what users really need without slowing down the efficient systems we’ve developed for delivering software!
The answer is dual-track agile.
Consider the typical agile product team, with product managers who:
- Process inputs like feedback & feature requests streaming in from users
- Generate feature ideas based on user needs and strategic considerations
- Prioritize the most valuable ideas, pushing them to the dev team’s backlog
- Discard low-value ideas or ideas that are infeasible to build
With just the top priority ideas on their plate, developers can deliver valuable features faster. That means feedback can be collected sooner, helping the product team further fine-tune what gets built.
But there’s a problem.
At the very least, we’re assuming user inputs can be neatly translated into requirements that product can send to the dev team’s backlog. Often they can’t. Users have complex needs with subtleties they may not even be aware of. Product managers who don’t take the time to uncover them are doing one of two things:
- Making assumptions
- Encouraging developers to make assumptions (by passing them fuzzy requirements)
In either event, they’re likely to get key details wrong, which threatens to waste the team’s time and degrade the quality of the product.
As a first-time product manager, I had to learn this lesson the hard way:
Building software, even efficiently, is an awfully expensive, frustrating, and suboptimal way of discovering what users really need.
- Expensive because software is time-consuming to code and maintain. Isn’t there a faster, cheaper way to learn?
- Frustrating because developers don’t enjoy committing to build potentially infeasible features with fuzzy requirements in tight timeframes, particularly when it might all be for naught.
- Suboptimal because blindly iterating on an arbitrary feature idea until it’s deemed valuable means not spending that time delivering another feature that is best aligned with the needs of your target market and overarching product strategy.
In short, why risk investing in building the wrong feature if you can first validate your understanding of the existing need and the ideal solution?
By introducing product discovery to our process we can do just that:
The discovery cycle is the process of actively capturing, researching, and prioritizing user needs — as well as collecting and validating solution ideas for addressing them. It complements the delivery cycle, which efficiently transforms validated product ideas into valuable product functionality.
At productboard, our product discovery process begins while communicating with prospects and customers on Intercom, over the phone, or in person during office visits and meet-ups. Customers routinely make requests or mention painpoints they have with our product today and our job is to dig deeper to understand what they really need–what they are really trying to do.
“Hi there, I see you recently asked for a dashboard exports capability. Would you mind helping us understand why you’re trying to export your data out of the tool?”
Product discovery can also be carried out more formally by interviewing users to delve into the context of their requests:
“We certainly appreciate you taking the time to screenshare your existing system of hacked together spreadsheets. It’s clear that prioritizing with a RICE score is critical for you. Mind if we take a screenshot to add to our research?”
With a clear understanding of the user need, PM and UX can team up to craft cheap prototypes and validate their understanding of optimal solutions for pressing problems. Anything that can help you get the highest quality feedback with the least effort will do here, even paper prototypes, UI sketches, or proposed capabilities outlined in a document. (How much you invest at this juncture depends on time constraints and the cost of executing on faulty requirements.) Ultimately, the aim is to understand:
“If we built feature X like this, would you use it?”
If feedback is positive, the prototype itself can serve as a feature spec when the feature is sent along to the delivery team, saving additional effort down the road.
For more on problem & solution interviews, we recommend Ash Maurya’s Running Lean.
Still, collaboration between the discovery and delivery teams is more than simply passing off requirements and deliverables from one team to the next — “mini-waterfalls within Scrum”, as Marty Cagan calls it. For example, with limited time and resources, the discovery team might call on a technical lead early on in the process to help rule out ideas that would be infeasible to build. Likewise, developers may take part in the tail end of the discovery process for a given idea, giving them opportunities to glean valuable context and raise flags well before delivery begins. Together, the discovery and delivery teams form a super team, responsible for bringing value to the customers. The super team only works when members from both teams collaborate to discover, validate, and deliver solution ideas.
For a more detailed overview of dual track agile, particularly within the context of Scrum, see Kevin Albrecht’s superb article, which inspired many of the ideas in this post.
With a clear sense of what it might look like for the what (discovery) and how (delivery) functions to work in parallel as the two interlocked gears of a well-oiled product machine, only one question remains:
What tools can teams use to manage it all?
We’ll cover that in part III! Coming soon.
