Tag Archives: product canvas

Different worldviews of your product

Ash Maurya published an excellent post he titled, “The Different Worldviews of a Startup”1, in which he made the following astute observation:

“Different people — entrepreneurs, customers, investors, advisors, all see a startup differently.” — Ash Maurya

Spot on. He starts his post as follows:

In his book, “All Marketers Are Liars Tell Stories”, Seth Godin defines a “worldview” as the set of rules, values, beliefs, and biases people bring to a situation. He offers a strategy of not trying to change a person’s worldview, but rather framing your story in terms of their pre-existing worldview.

Boy, I wish I had this insight when I started out as a product manager! It totally applies to how product managers need to manage their stakeholders and partners with respect to their products. You need to tailor how you pitch your product strategy or business case to your audience based on the things they really care about.

And so with all due respect to Ash’s post, I will take the liberty of adapting his post to the discipline of product management. Similar to what he did in his post, I’ll illustrate this concept using the Product Canvas. If you’re unfamiliar, it’s a one-page encapsulation of the most essential elements that define your product strategy.

The Product Canvas

As Ash pointed out, different people see your product differently. I’ll expand on Ash’s post by discussing the different world views according to some of the different stakeholders a product manager has to deal with inside an organization.

Product Managers

Product Manager's world view

Product Managers, particularly those from technical backgrounds, are naturally drawn to the Solution box. Even yours truly. 🙂 They tend to spend a disproportionate amount of time on defining the features of their solution. As Ash puts it, “they fall in love with ‘awesome’.”

That’s why, like Ash did with his version, I kept the Solution box on the Product Canvas purposely small. This is not to replace user stories or a proper product definition. Rather, for one, to think about what are the most important elements of your solution that satisfy the primary problems of your target customer, as captured in the Problem box. Secondly, to make clear that the other components of your product strategy are equally, if not sometimes more, important.

Customers

Customer world view

I want you to write this down. Ready? Here it is:

Customers don’t care about your solution.

Write it down. Read it. Read it again. Sear this into your brain. Live it. Breathe it.

Customers care about only one thing: solving their problems. So to get them to care about your product you need to convince them that you understand them (identity), and then offer them something compelling that will solve their problem (your value proposition). How many times have we been told as product managers that customers don’t buy features, they buy benefits?

If you get these first two right, their next question is, “What’s it going to cost me?”. What they’re evaluating here is whether the price of your proposed solution is commensurate with its perceived value. (Value as perceived by them, not you.)

VP of Marketing

VP of Marketing world viewMarketing folks tend to naturally think about the market and customer first. Your VP of Marketing will be thinking about who are your target customers, what’s the plan to reach them, and how to measure the success of any marketing efforts. They know customers are bombarded with lots of noise, so your Marketing VP will be keenly interested in how the value prop of your product will be messaged, and its competitive positioning. (You do know who your competition is, don’t you?)

VP of Sales or Business Development

VP Sales worldview

Sales is interested in customers from the perspective of having a pipeline of hot leads. In particular, Sales will be trying to figure out who is that first named customer to whom they can take your product and quickly close a deal.

Sales folks love to talk about a product that “sells itself”. What they’re saying is they want you to have figured out who the customers are, and that you’ve built a massively appealing solution for them such that they’re thirsting for your solution.

Sales will also be keenly interested in pricing. It’s not just about their commission. (Well, it is about their commission, but stay with me here.) Many Sales folks look myopically at just price, because they’re worried about being undercut by a low-cost competitor. However, a good Sales or Business Dev exec will want to ensure your product’s price not only provides enough margin, but also communicates a value perception to the customer.

And that gets us to competition. Sales wants to be well-prepared before getting in front of customers. So be prepared to talk about what solutions customers may be using or considering, and how your product is positioned against these alternatives.

VP of Operations

VP Ops world view

Ops will want to assess the operational risk of delivering, fulfilling, distributing and supporting your product and marketing efforts. Ops will want to talk about business processes — if existing ones will be leveraged, will they need to be changed, or new ones created. And they will be looking to do these as efficiently as possible.

VP of Engineering / CIO

VP IT world view

When I talk software engineering folks through the Product Canvas, one of the most common questions I get is about capturing technology risk. They want to understand what it is you’re asking them to build (business/product requirements) so they can assess impacted systems and platforms, resource assignments, and architectural fit, in order to estimate the level of effort. They’ll want to understand if your product will require new technologies to be adopted, and if so, what that means in terms of skills sets and integration requirements. These considerations will impact the cost of developing, building and supporting your product.

Executives

Executive world view

Ok, saved the best for last…

Here, I’m talking about the senior execs in your organization who prioritize resources and approve operational budgets and capital investments.

Now, I want you to write this down too. Ready?

Executives don’t care about your solution.

Ok, maybe that sounds harsh. Maybe they do care. A little. But what they’re really doing is weighing your product as an investment. In other words, ROI. Similar to startup investors, executives are weighing the risks and opportunity costs of your proposed product strategy. Because they could easily allocate resources to something else they deem more worthy.

Executives do care about the customers you’re targeting, but less in terms of who they are, and more in terms of how many. In other words, market size, or more specifically, the addressable market.

They also want to know how much of it can be captured — in other words, market share. They’re doing the math of multiplying those numbers against the intersection of your revenues and costs to figure out the potential ROI.

For them to believe in your proposed ROI, they’re going to be interested in metrics. How will you know you’re being successful? What milestones will you need to hit? You need to figure out what metrics have line of sight to revenue and profit.

Ash makes a great point about traction: “If you have good traction, you can almost always convince the right investor to write you a check.” True for product managers too. If you can demonstrate traction, you’re more likely to get buy-in from your execs, and that means knowing how you’re defining and measuring success.

Finally, executives are often concerned about brand defensibility and differentiation. Especially in the case where the company has made heavy investments in its brand, execs will be evaluating whether your proposed solution will have a beneficial or detrimental impact on brand value.

Each of the boxes in the Product Canvas represents a risk or objection you must overcome towards building a successful product strategy. The true job of a product innovator then is to systematically de-risk their product strategy over time. To quote Ash one last time, “It helps to appreciate the different world views other people carry with them and frame your story accordingly.”

1“The Different Worldviews of a Startup”, Ash Maurya, LeanStack

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.

“Stakeholder Development”: Using Customer Development on Internal Stakeholders

In my last post, I introduced the Product Canvas — my iteration of the Business Model Canvas — as a simple and quick way to capture my idea for a product. I’ve also used it as a communication tool to share my product vision and get early feedback, which is critical in the beginning stages of exploring a new product opportunity.

I’ve been sharing the Product Canvas with anyone who’s asked, and early feedback has been encouraging. One of the biggest things that seems to be resonating with folks is the Key Stakeholders box.

Product Canvas - Key Stakeholders

Look, I’ll admit, managing stakeholders is cumbersome, tiresome, and at times a pain. There, I said it. Admit it: you’ve felt that too. In my research on the business case process, a large majority stated that maintaining stakeholder support and alignment is important, but a challenge.

But I’ve learned the hard way that identifying and aligning stakeholders is really important for any initiative. So that’s why I put it in the Product Canvas. The reality is lack of stakeholder support can kill any brilliant idea at any stage.

When I came across Steve Blank’s Customer Development methodology, I wondered if its principles could be applied to internal stakeholder support. In other words, I wondered if it was possible to “develop” stakeholders too?

Here’s the Customer Development process. Steve’s bottom-line advice is to “get out of the building”.

Customer Development

So if apply this to “Stakeholder Development”, I’m thinking the process would look something like this:

Stakeholder Development

In this case, the bottom-line activity is to “walk the building”!

I figured this provided me as good a workable framework as any to identify, build and grow stakeholder support, and then I decided to put it to the test.

Through much trial and error, here are some tactics I’ve applied to Stakeholder Development. I’ll admit I haven’t fully cracked the code, and continue to experiment and learn. By sharing here, I’m hoping others may try as well and share their feedback.

I try to follow a systematic process for identifying my stakeholders, sharing my vision, capturing their feedback, and creating traction. I’ve been experimenting with applying Lean Startup’s Build-Measure-Lean loop for the purposes of doing this, and over time, I’ve developed a basic meta pattern:

stakeholder_dev_loop

So now that I’ve got a workflow I can follow, my first step is to identify who I think are my primary stakeholders, and I capture this in the Key Stakeholders column of my Product Canvas. Sometimes I already know ahead of time. In that case, I simply list them in the Product Canvas. But I have been in situations where I wasn’t entirely sure who were my key stakeholders. In this case, I capturing my hypothesis for who they may be.

I also try to identify a possible executive champion or sponsor – something I’ve learned is practically a requirement in a larger organization to ensure the success of any initiative.

So my Product Canvas could look something like this:

Product Canvas - Key Stakeholders example

I’d have actual names in the box, of course. If I don’t know who my executive sponsor will be (insider’s tip: it’s not always your boss), I don’t put a name, but I definitely call it out so it’s always at the forefront.

Next, I formulate hypotheses to approach my potential stakeholders. Going back to the Stakeholder Development flow above, notice a key question is “What are their agendas?” Remember: everyone has their own set of priorities. Some are visible, like a project deliverable; but some are invisible, like organizational political pressures. (Like it or not, these exist.) The more knowledgeable I can about their priorities, the better I can position myself to either gain their support or counter their arguments. At worse, I’ll have identified a potential detractor early on.

I then “walk the building”, reaching out and setting up meetings. For stakeholders with whom I don’t have a close relationship, who barely or don’t know me, I try to figure out ways to get an intro, just like one would do with customer interviews.

Setting up and conducting these conversations may be time consuming, but they are invaluable to validate who are my real stakeholders, and what I’ll need to do to get their buy-in.

I maintain a simple log to track my progress that I call my Stakeholder Development Tracker:

Stakeholder Development Tracker

There have been times I’ve discovered that someone who I thought would be an important stakeholder, actually isn’t. Great: I just mark their Role and Status as as N/A, and move on. Other times, I discover that someone I originally hadn’t identified is actually going to play a significant role in the approval and/or execution of my project.

Stakeholder Development Tracker Example

As I validate who are my true stakeholders, I update my Product Canvas.

product-canvas-key-stakeholders-iteration

These stakeholders are the ones I really want to focus on, the ones with whom I want to create traction. If I play my cards right, I can convert them from supporters to advocates to where they are actually personally vested in the success of my initiative.

As I said, I’ve been experimenting with this as a framework. It’s a work-in-progress, and I’ve enjoyed some success. Give it a whirl yourself, and let me know what works or doesn’t. If you have an approach to Stakeholder Development that’s worked for you, please share.

How I Document My Product Vision

Over the last many years, I’ve been experimenting with applying Lean Startup andThe Lean Startup Customer Development concepts to product management. I first wrote about this here. Some time ago, I wrote about the challenges I and other product professionals have faced with the traditional approach of writing a business case.

One area where I had always struggled with was finding a simple and quick way to sketch out my product ideas. I used PowerPoint, Word, Google Docs, but they never really worked effectively. Often times my original notes would grow into a bloated morass of detailed thoughts about features, customers, marketing, partnerships, technologies, etc. There was no structure. Worst of all, if I wanted to share them with someone, I’d have to spend time figuring out how to translate them into something readable, since no one would be able to decipher my chicken scratch.

Before writing a requirements doc or business case, what I really wanted was a way to not only quickly capture a product idea in a structured manner, but also use the same format to share it with others to elicit feedback.

So you can imagine my delight when I came across Alex Osterwalder’s Business Model Canvas several years ago.

Business Model Canvas

What’s great about it is since it’s a single page, one can quickly jot down the basics of any business model, and it’s easy to share and more likely to get read than a PowerPoint deck or a Word doc. The single page also forces brevity: there isn’t a lot of space for a laundry list of features – you need to distil down your idea to its most essential building blocks.

Love at first sight, I started trying to use it for my products. But I ran into a few challenges. I found that while it does a good job capturing the key elements of a business, it’s not as customer focused as I would have liked because there was no place to capture the customer problems I was trying to solve or identify potential early adopters. There was also no place to capture my envisioned solution, and I often got confused between Channels and Customer Relationships.

That’s when I came across Ash Maurya’s Lean Canvas, an adaptation of the Business Model Canvas he created for his web startups.

Lean Canvas

Ash has correctly put the focus on customers and their problems. I also like that he calls out Unfair Advantage, which to me means competitive differentiation. This is especially true for a startup that may be fighting bigger, more established players.

So I started using his Lean Canvas, but ran into a new set of problems as a product manager:

Resources: Ash has left this out from Alex’s original version. I can understand this with respect to startups, but as a product manager working in an organization, it was important to me to identify which resources – platforms, systems, departments, vendors, etc. – I would need to make my product idea a reality.

Readability: When walking someone through a product or business idea, my inclination is always to start with the market opportunity, which means customers, their problems, and how we can solve them. I found neither of the above two canvases easily lend themselves to that flow. I’d have to start at the right-most column and then jump back left. This is non-intuitive to most English-speaking readers, and I found I’d quickly lose my audience as I criss-crossed columns.

Two other challenges I ran into as a product manager:

Stakeholders: Product Managers have to deal with internal stakeholders. The larger the org, the more. Often times a new product idea needs an executive sponsor. In my experience, I’ve found that the more I’m mindful of who are my key stakeholders, the greater the chance of internal support for my product.

Non-Revenue “Products”: Some products managers are responsible for initiatives that aren’t directly revenue generating, but do provide tangible business value, like improving CSAT, driving referrals, etc. I’ve lead several like that.

So I decided to create my own iteration that I felt was more suitable to me as a product manager, that I call the Product Canvas:

This version puts the customer and market on the left-hand side, which not only addresses the readability issue but also supports more intuitively how I think through a product opportunity. I can start with the customer and their problems on the left, and work my way toward the right to ultimately figure out how I’m going to deliver on the solution.

Here’s a brief description of each block and the order in which I typically approach them:

1. Customer Segment: Who is the target customer of our proposed product? This could be the company’s entire customer base, a segment, or a new market or vertical. Ash recommends using a separate Lean Canvas for each segment where one has multiple segments in mind, and I think that’s good advice as a starting point.

1a. Early Adopters: For any new product opportunity, it’s important to identify early adopters. There is already a ton written about this. While identifying early adopters is implied in the Lean Canvas, I wanted it called out explicitly, as I’ve found even in existing organizations there is a tendency to think any new product idea is applicable to all customers.

2. Problem: A brief description of the top problems we’re addressing. I try to limit this to at most 3.

2a. Existing Alternatives: How is the customer solving this problem today? This may not be just direct competitors. For example, in the early days, Quicken’s competition was not only other accounting software, but also checkbooks, and pen and paper.

3. Unique Value Proposition: How are we uniquely going to solve our customers’ problem(s)? This is the elevator pitch: the one sentence that clearly states the value we’re providing to our target customers.

4. Solution: What are the most essential features of our solution that will deliver on our UVP? This is not an exhaustive feature list. I try to limit it to the top 3 elements of my proposed solution.

5. Channels: How will we get (acquire), keep (retain), and grow (sell more to existing) customers? What is the marketing and sales strategy?

6. Revenue Streams/Business Value: How will we make money? What’s our pricing strategy? If this is not a revenue generating product, what other business value is it providing? Improving customer satisfaction? Customer lifetime value? Market positioning? Competitive differentiation? Operational efficiencies?

7. Key Metrics or Success Factors: What are the most important metrics that will tell us that we’re successful? Signups? Conversions? Referrals? CSAT? NPS? These are the metrics that are driving #6 above.

8. Key Resources: What are the most critical internal resources we need? These could be platforms, systems, business processes, departments. Are there external partners we need to rely on?

9. Cost Structure: What are the key cost drivers? Software/IT development? Customer acquisition? Account management? Hiring and talent development? This is also a good place to capture a back-of-the-envelope break-even calculation.

10. Unfair Advantage: This is the distinctive competence or advantage that your product has over other solutions in the marketplace. It’s something your product does better than any other, something that can’t be easily copied. It could be intimate knowledge of an industry, personal authority or brand, a business process or competence, a patent, or some other intellectual property.

After experimenting with using this Product Canvas as a product manager, I started sharing it with folks, asking them to use it, and the feedback has been very encouraging.

Feel free to download it here.