The Age of Product Discovery: Part I

Quick. How many tools can you think of that help teams manage how software gets developed & delivered?

Answer:

• JIRA
• Pivotal Tracker
• Trello
• GitHub
• Asana
• GitLab
• Leankit
• dapulse
• Targetprocess
• Basecamp
• Teamwork Projects
• Rally/CA Technologies
• ZenHub
• HuBoard
• Overv.io
• Blossom
• YouTrack
• sprintly
• FogBugz
• Cnverg
• Clubhouse
• Wrike
• Waffle
• Codetree
• Microsoft Visual Studio Team Services
• TeamGrid
• WorkingOn
• Redmine
• Planbox
• Active Collab
• Podio

Now how many can you think of that help not with managing how software gets built, but deciding what gets built in the first place?

• productboard
• ProdPad
• Aha
• Wizeline

What’s going on here? Take a look at when the most popular tools in each space were launched:

It’s almost like sometime around four years ago, we all finally realized:

What’s the point of optimizing the delivery of software if we’re not delivering the right thing?

But it’s not that we never cared about deciding what to build. It’s just that what has always lagged a little ways behind.

There’s nothing new about the “what”

For over 25 years we’ve had helpful frameworks for discussing what users need and what to build to address those needs. This is no new concept. (❗) It was back in 1991 when IDEO began popularizing the notion of design thinking — using rapid prototyping to iteratively uncover users’ needs and design optimal solutions. Still, these methodologies were only used by isolated teams until more broadly adopted over a decade later.

Indeed, the 90s were largely a time of optimizing marketing and engineering execution rather than systematically validating user needs. This came at a heavy cost. In the opening chapters of The Four Steps to the Epiphany, Steve Blank details how WebVan, the early grocery delivery service, was so busy marketing at users and building hundreds of millions of dollars of infrastructure, they overlooked the fundamental needs of their target market. $1.2 billion dollars later, they learned some of their early assumptions had been incorrect and filed for bankruptcy in 2001 at the height of the dot-com collapse.

And there wasn’t just a disconnect between business models and user needs. It existed at the feature level as well. In The Inmates Are Running the Asylum (1999), Alan Cooper makes an urgent call to refashion the feature-centric view of product development, divorced of the needs features were meant to address. His writings helped redefine the role of product managers and solidified user experience design as a field in its own right.

As it sorted through the ashes of the dot-com collapse, the tech industry was primed to reconsider the role of the product team. Who better to lead the industry’s recovery and a new paradigm shift than the guy known for his theory that creative leaps come from destruction — Clayton Christensen. In Innovator’s Solution (2003) Christensen re-popularized the notion that users “hire” products to achieve some outcome, to get some “job” done. His jobs-to-be-done approach serves as a helpful framework for tailoring new feature to users’ underlying needs– whether you’re making software ? or milkshakes ?.

In the years that followed, Steve Blank worked to apply many of the same ideas that inspired agile methodologies (on the how side) to the what side. One of the core tenets in his Customer Development framework (2005) was eliminating wasted effort (building features no one wants) by learning faster. A startup bringing a new product to market is making tens (even hundreds) of assumptions about the best way to design the product and deliver it to their users. Better to actively identify these assumptions early on so they can be tested before significant effort has gone into building a product no one really wants. Eric Ries, a student of Blank’s at UC Berkeley, channeled these ideas into The Lean Startup, expanding on Customer Development by detailing specific practices startups (and any product team) can use to iteratively test hypotheses while pivoting from cheap prototypes to successful products.

More recently we’ve seen a resurgence of interest in jobs-to-be-done, with Intercom’s popular blog posts and e-books (2013–present). Others have reframed jobs to further refine the way we discuss what users really need. In Value Proposition Design (2014), Alexander Osterwälder and Yves Pigneur describe a product’s core value proposition as a function of the user pains it solves or the positive gains it provides. As they show, solving pains and delivering gains is the foundation of every business model.

“What” frameworks have advanced but the tools haven’t

Returning full circle, the frameworks we now have for discussing and optimizing both the how and the what of product development have advanced considerably over the past two decades. But tools for managing each have advanced at different rates. As an industry, we’ve favored the how to the detriment of the what. And that means that until now, product managers have managed the complex process of deciding what to build next using hacked-together spreadsheets, shared docs, task management tools, and systems for managing engineering, sales, marketing, and support data.

Without dedicated systems for managing the what, teams are more susceptible to losing focus, building the pet features of the highest-paid executive in the room, or being swayed by the demands of their largest, loudest customers — even if doing so is less likely to help their product succeed in the longrun. That’s a shame, because it means teams have collectively wasted hundreds of thousands of hours and billions of dollars developing underutilized features and products that failed to live up to their potential.

Don’t get me wrong. Optimizing the how hasn’t all been a waste! I too appreciate efficient software delivery. Being able to adapt to changing requirements, collaborate seamlessly, and improve continuously have led to higher quality software, and more efficient, motivated teams. And because product increments are getting shipped sooner, teams collect feedback in less time, and that helps teams optimize what to go work on next. The how and the what are interrelated after all!

All the same, building shippable software is an expensive way to refine your understanding of what users need. And even then, by limiting ourselves to learning from one product improvement at a time, we risk being blinded by the haze of incrementalism, unable to see if we’re working on the optimal product or feature set to begin with:

So how might we go about deciding what to build at the same time as we’re optimizing how we build our products? We’ve got just the system for you! And we’ve written about it in Part II.