Tag Archives: innovation accounting

How to Identify (and Mitigate) the Riskiest Parts of Your Product Strategy

Any product strategy is fraught with risks.

Three of the biggest risks to a startup are tech risk, market risk, and ego risk. Corporate innovation faces additional risks: resource risk (resources need to be assigned), implementation risk (need the right implementation skill sets and tools), operational risk (the product needs to be operationally cost-effective) and internal risk (need buy-in and alignment from internal stakeholders).

Identifying these risks and de-risking them are crucial to the success of any product strategy. One of the most compelling things to me about Lean Startup is the focus on systematically de-risking elements of a product innovation through experiments and Validated Learning — one of the five core principles of Lean Startup.

Of course, this is predicated on identifying each of the most essential elements of your product vision. The Product Canvas has been great in helping me do just that. Its 1-page format facilitates having important conversations with my partners and stakeholders to gather their feedback.

“[The Product Canvas] is a smart way for each product manager to have a succinct snapshot of what it means to ‘be’ a product. It is a great way to focus and present to others the critical elements of a product.”

Having conversations with my internal partners are critical to helping me uncover risks and assumptions that I may not have thought of.

As I started doing this, the question became how to capture these risks, track progress in de-risking them, and communicate back that progress?

Here, again, is where I found the principle of Innovation Accounting from Lean Startup appealing, which Eric Ries describes it in his book:

To improve entrepreneurial outcomes, and to hold entrepreneurs accountable, we need to focus on the boring stuff: how to measure progress, how to setup milestones, how to prioritize work. This requires a new kind of accounting, specific to startups.

In other words, Innovation Accounting provides a framework to measure and communicate progress. The unit of progress is a learning milestone, “an alternative to traditional business and product milestones.” (From the book.)

This last part really appeals to me. Developing a grounded, workable product strategy cannot be moved forward by a date-driven approach, and I’ve seen too many new product development efforts descend into chaos, and even outright failure, by the traditional project management process.

Again, from Eric’s book:

“Learning milestones are useful for entrepreneurs as a way of assessing their progress accurately and objectively; they are also invaluable to managers and investors who must hold entrepreneurs accountable.”

I’d argue we could replace “entrepreneur” with “product manager” or “product innovator”, and “investors” with “executives”.

But again, the question is how to actually do this in practice. Let’s go back to the issue of capturing and tracking assumptions and risks.

At first, I used stickies:

pmc_hypotheses_1_lowrez

That worked great as a start. Especially for brainstorming or a live update if a colleague or stakeholder was in the room with me.

But not so much for tracking ongoing progress. Plus, translating all that into an update report to share with someone not in the room is just too much work, quite frankly.

I needed something that doubled up as a tool to use and a way to communicate progress, similar to the Product Canvas.

Then I came across Ash Maurya’s blog posts on his Lean Stack approach to doing Innovation Accounting. I liked how he’s mapped the Build-Measure-Lean cycle into a Kanban style approach to track his progress.

After experimenting with his approach, I developed a version that worked for me as a product manager. I’ll explain via a made up, yet tangible, example.

Below is an initial Product Canvas for an online bill payment app that allows customers of a bank to view all their bills in one place and pay directly through their bank account.

billpay-product-canvas

Now, as product manager, I should be intimate with my customer base. So let’s say their input was the genesis for this product — e.g., lots of customer requests asking to enhance the existing bill pay service with the ability to view and pay utility bills.

As such, initially I may not see my Customer Segment or Problems as the highest risks. But I do need to identify my early adopters.

In other words, I feel confident in the initial demand, but I’m not certain which of my customers will be most likely to switch their behavior to paying all their bills through our bank. (After all, people don’t always do what they say.) So I highlight this as a risk.

After speaking with my stakeholders, I identified numerous additional risks, which I highlight via PowerPoint’s comments feature:

billpay-product-canvas-with-comments1

All I need to do is click on any comment to view the details:

billpay-product-canvas-with-open-comments

Now, to track and communicate progress on how risks are being addressed, I use a Kanban style board similar to what Ash uses, called the Validated Learning Board.

billpay-validated-learning-board

Risks and assumptions are placed in the Backlog column. When I begin working on a particular risk card, I move the card to the IN PROGRESS section. I place a blue card under the Build column to note the experiment I’m conducting. On the card, I note the experiment that I’m running and the falsifiable hypothesis of my experiment.

If an experiment serves to tackle more than one risk, no problem. You’ll see an example in the image above representing that.

Once I start the experiment (e.g., interview the first customer, or day 1 of user testing, etc.), I move the card to the Measure column.

Once the experiment is over, I move the risk card to the Learn/DONE column, and color code it green if the assumption has been validated or risk de-risked, and red if not.

If I’m running multiple experiments simultaneously, I separate them with a line.

billpay-validated-learning-board-2

I don’t capture all the details of my experiment on the cards. This is meant for a high-level progress view. Details of the experiment can be presented on its own slide or report.

Finally, I need to make sure I’m systematically identifying the right set of internal stakeholders and capturing their feedback. I covered that in my blog post on Stakeholder Development, in which I talked about the Stakeholder Development Tracker.

As I continue to get feedback from both the experiments and further internal conversations, I use these learnings to update the product strategy represented in the Product Canvas.

A team can use these artifacts to track progress on, say, the wall of an agile room, while also quickly converting them into 3 quick slides to provide a high-level update to anyone on the progress of the product strategy.