Product Management Discovery vs Assumption

Recently, I had the pleasure of leading the product management discovery for a company's new product. I was impressed by their desire to reduce risk, time, and costs in creating this new product through their first time using Agile Product Management.

I've enjoyed the proactive nature of creating discovery and risk backlogs upfront and then investigating problems and pain aspects with existing and prospective customers. We used interactive product prototypes to test and receive customer feedback, using rapid prototype revisions to obtain clarity on the minimum viable product to build for successful sales engagements. We worked as a single team, with engineering involved with the agile discovery project from day one. Their input was invaluable, especially around the technical viability aspects of the product.

The product sprint backlog is currently being defined using the upfront discovery, risk, and prototype investigation work, and the engineering team will soon begin developing the identified minimum viable product.

I've found that most companies will say they use Agile techniques. However, many are still using a Waterfall-type approach within product management and are only really Agile within engineering. Companies generate appealing ideas internally, then write a best-case and assumption-laden product requirements document. They guess the budget, required team, time, and minimum viable product, then present the most optimistic plan and revenue figures to the board for approval.

As Clayton M Christensen explained, "... by the time they have learned which assumptions were right and which were wrong, it's too late to do anything about it. In almost every case of a project failing, mistakes were made in one or more of the critical assumptions upon which the projections and decisions were based. But the company didn't realize that until it was too far down the line in acting on those ideas and plans. Money, time, and energy had already been assigned to the project; the company is 100 percent committed; and the team is now on the line to make it work. Nobody wants to go back to management and say, "You know those assumptions we made? Turns out they weren't so accurate after all..."

I've found it common that companies follow this non-agile approach in product management when defining and developing a product. Once created, the product is only then taken to market for customer validation, often with unsuccessful and failed sales results. Some of the actual products I can think of have had an annual nine-figure product and engineering budget for the ultimately unsuccessful product.

Of course, there are no guarantees that the product will succeed in the market. Still, the probability is significantly higher because the company used Agile Product Management techniques before engineering began to build anything. Also, notably, the company's risk and cost of misaligning the product-to-customer match is significantly lower.