Tag Archives: Product Manager

The Top Strategies For Doing Customer Interviews That Get You Real Insights

We all know a core responsibility of a product manager is to constantly and consistently bring the customer perspective into the business.

That means customer interviewing is a critical skill for every product manager.

I must admit, earlier in my career I totally sucked at it.

I had no plan. I often just winged it. I asked the wrong questions. I was a poor listener. I talked more and listened less. I tended to get too excited about my product idea and go into pitch mode instead of focusing on the customer’s problems. And I was very guilty of confirmation bias.

Fortunately, with lots of practice, over time I got better. As I did, I accumulated a list of the best strategies that I use even today to conduct an interview that helps me extract real customer insights.

Get the Entire List of 25 Customer Interview Strategies >>

So in this video I share 5 of the best customer interview strategies:

Use these 5 powerful tips to supercharge your customer interviews to extract every ounce of goodness from them:

  1. Set an objective. Know what you want to get out of the interview — that is, what is it you want to learn and come away with?
  2. Have a script. Having a script will help guide your interview with the customer, be better prepared and purposeful in your interviewing, and make sure you achieve the objective you’ve set out.
  3. Ask “Why?” — a lot. This is by far the most important question in your arsenal. It allows you to go deep, get inside the mind of your customer, understand their motivations, get to the true nature of the problem they’re trying to solve, and how they actually value their solutions.
  4. Ask for examples. Asking for an example forces your customer to get specific rather than speak in generalities, giving you tangible evidence of a customer’s problem, and allowing you to momentarily “live in their world”.
  5. Focus on listening. Cannot stress this enough! The biggest thing you can do is to TALK LESS AND LISTEN MORE. Your purpose is to get THEIR perspective — not promote your point of view, explain yourself, defend your idea or debate. The only times you should look to speak is when you need to clarify something or need to ask a follow-up question.

Get the Entire List of 25 Customer Interview Strategies >>

Follow these strategies and you’ll become a pro at conducting truly insightful customer interviews.

Watch the video above, download the full list of customer interview strategies, and please share in the comments below what strategies you’ve developed to conduct truly insightful customer interviews.

How Do You Become A Good Product Manager?

This is the BIG question, isn’t it?

We all want to be the best at what we do.

And product managers are no different. We want to be good. Great. Awesome.

And we want to be recognized for it!

We want to launch products people love. We want customers to love it. Our company’s to grow from it. Our teams to feel pride in it. Competitors to fear it. And our executives to love us for it.

So how does one become a good product manager?

Unfortunately, there’s no one size fits all answer to this. There’s no silver bullet or 3-step process that guarantees you will become a good product manager. (Let alone a great one!)

But it’s one of the most frequently asked questions. It gets asked at ProductCamps. It’s asked on Quora in different ways. And it’s one I’ve been asked countless times by folks I’ve mentored, by peers, even CEOs and senior executives.

Lots of knowledgeable and seasoned product management practitioners have weighed in on this. Some really good perspectives from some really smart, successful product managers.

So today I weigh in with my perspective. While there’s no single universal answer, I do believe there are some key principles or strategies you can adopt to become a really effective product manager.

And that’s what I share in today’s video.

Through product management gigs in startups and Fortune 100 companies, I’ve come to identify seven principles that help me as a product manager in any situation:

  1. Get to know your customer.
  2. Get to know your product.
  3. Learn the business.
  4. Learn the market/industry.
  5. Learn how to execute.
  6. Find mentors.
  7. Invest in yourself. That is, look to constantly upgrade your skill set.

The last two are really the key to unlocking your full potential as a product manager.

Are any of these new to you? These are sort of “no brainers” to me now, but looking back, if I’m honest with myself, I probably focused a bit too much on #2!

It can take time to master these, but I’ve come to realize they’re paramount to successfully execute as a product manager.

You can read my original answer on Quora, as well as some great answers to another similar question on Quora.

Watch the video and then please leave me a comment below on what do you think it takes to be a good product manager?

Here’s to all of us becoming great product managers!

13 Myths And Misconceptions About Product Managers

The good news: when it comes to software, product management is now being seen as a legitimate profession and increasingly critical to a company’s growth strategy.

(Ok, maybe it was always thus in Silicon Valley, but the rest of the world is now catching up.)

The bad news: There are still many myths and misconceptions folks have about our profession.

Here are some common ones:

  1. Product Managers are proxies for project managers.
  2. Product Managers are “technical people”, so it’s not necessary to involve them in business, sales, marketing, pricing or (worst of all) strategic discussions.
  3. Product Managers are “technical people”, so naturally they define/understand the database structure, system design, server configurations, etc.
  4. A Product Manager is a “technical role”, so must sit under Engineering or IT.
  5. A Product Manager’s primary (only?) job is writing requirements…
  6. …And how hard can that be? (One of my favorite quotes from non-PMs: “I could write those requirements over the weekend.” Go for it, boss.)
  7. If the product has a technical issue, like something wrong with the data model, SQL stored procedure, or the system design, the PM is responsible and answerable. (Uh, no.)
  8. A Product Manager can come up with a product roadmap without a well-defined product strategy.
  9. A Product Manager can come up with a product strategy without a well-defined business strategy.
  10. A roadmap is simply a case of plotting a bunch of features on a timeline with dates. How hard can that be?
  11. The Product Manager must come up with delivery estimates and dates, and stay true to them no matter what. (Because we product manages are fortune tellers, of course.)
  12. The Product Manager must spend most or all of their time with the development team / in the scrum. (Nope. They must equally spend time, if not more, in the market.)
  13. The Product Manager is “CEO” of his or her product. (Nope. The CEO is the CEO.)

No, I Can’t Give You A Roadmap For Our New Product (Yet)

Cartoon by Roger LathamA fellow product manager that’s working on a new product idea recently wrote to me:

“Common feedback I receive from our our engineers and executives is they don’t have a good grasp of the product vision. They say, “OK, that’s great, we can build that. But where are we going with this if we find the hypothesis to be true? What’s the long term vision for the product?” In essence, they’re asking what’s the end goal in 2-5 years, and if you show me that I’ll have a better sense of the architecture and tools I need to account for.”

This product manager is right at the very initial stages of their product idea, where he still needs to test the problem and solution hypotheses. But he’s already being asked for a long-term product roadmap! Sound familiar?

While the request may seem perfectly reasonable, it’s misplaced at such an early stage. The question about architecture and tools may also seem perfectly reasonable on the surface, but it’s a scale question, and is not the right one to be focusing on before you know if you’ve even identified the right customer problem and have proof that your solution approach is viable to solving that problem.

Execs are trying to assess the potential market opportunity, the underlying investment that will be needed, and the speed to achieving ROI. So naturally, they want to see the long-term roadmap. But at such an early stage, you’re likely in no position to be able to answer the question.

Even at the conceptual stage, you may have a list of potential features in your mind. You could prioritize them using one of the many scorecarding techniques written about by seasoned product practitioners. (See this, this, this, and this, to reference just a few.) These are all very valid techniques written by product folks who really know their stuff.

Doing that so early is a waste of time, though. Creating a product roadmap is predicated on having a coherent product strategy, which is predicated on having a validated understanding of who are your customers, what are their pain points, and whether they’ll find your solution valuable. If you don’t even know if customers will buy your solution, what’s the point in having a roadmap?

So when do you develop a roadmap for a new product?

For a startup product, the first step is always to identify the customer segment and customer problem. Quickly capture your product vision, formulate your customer, problem and solution hypotheses, and systematically test them. As you go along, you need to identify early adopters to whom you can deliver your solution — typically you build the product for these folks first. If practicable, test pricing at this stage as well.

Figure what you absolutely must deliver to these folks to solve their #1 problem, and work like hell to deliver it as quickly as possible. All other features get cut from scope and sit in the backlog.

After delivering this minimum viable product (MVP) you need to actively gain feedback from these early customers. You’re using your delivered product to gain deeper insights into the customer’s problem, and you’re trying to understand what you need to improve in the product to (1) get these customers to stick, and (2) attract more new customers.

In addition, now that you have an initial set of engaged customers, you can also try to test their second level set of problems or discover new ones. Understanding those problems may identify new enhancements and features. You’ll now be armed with a set of improvements, fixes and new ideas that you can put into the backlog.

If you have a sales force and have armed them to sell your MVP, make sure you’re actively gathering feedback from them as well. You may uncover opportunities to evolve your sales messaging and positioning. You may also uncover feature gaps. If so, you can put the into the backlog as well to earmark for further validation. Pay particular attention to customer feedback that’s preventing a customer sale.

You’ll have a pretty good backlog at this point, so you can now start building an initial roadmap. Start by prioritizing the backlog based on a reasonable customer-centric set of criteria. I typically skew my priorities heavily toward voice of customer (VOC) feedback. While at any stage of the product lifecycle, features should solve tangible customer problems, it’s even more important at this early stage.

Also factor in the company’s strategic goals. For example, if the company’s focus is retention, features that create stickiness may carry more weight; if the focus is growth through customer acquisition, then sellable features may be more important; if it’s expansion revenue — i.e., greater revenue from existing customers — features that drive engagement and up-sells may take priority.

Make some allowance for operational issues. You may not necessarily have a scale problem yet, so these type of issues should not take precedence over VOC or driving revenue; however, you don’t want to completely ignore technical debt or reasonable operational fixes.

Once you have a prioritized list, socialize it. (Read this post by Bruce McCarthy on using “shuttle diplomacy” to get buy-in.) For the top priority items on the list, get t-shirt sizing from Engineering, and make a final call to sequence out the items based on customer and business value vs. feasibility. Now you’ve got a validated product in the marketplace with a decent first-pass roadmap that you can build upon. Go forth and conquer!

5 steps to validate your product idea without a product

Here’s a scenario:

Top Exec at your company comes to you and says, “Yesterday, I was talking to Big Industry Player and they mentioned how they have Shiny Object. I think we should have Shiny Object too. How fast can we get it done?”

Sound familiar?

At a ProductCamp DC event a few years ago, my co-founder and I hosted a session called “Tales From The Product Frontlines”. Our first topic was about this very scenario. It so energized the participants that it took up 30 of the 45 minutes we had been allotted!

During the session, we asked folks questions like:

  • What do you do now to vet new ideas, whether your own or from some other source?
  • How is that working?

Most folks talked about having some sort of governance structure, such as an Executive Steering Committee, to vet new ideas based on some established criteria. Many talked about the need to create a business case. Some advocated that Product Management is best suited to do that, regardless of where the idea came from.

Yet, after the session, every person I spoke with told me they felt writing a business case was a total waste of time.

What gives?

The old ways just don’t work

Pragmatic Marketing’s 2013 survey revealed that product managers spend over a month’s worth of time writing business cases. These business cases are filled with highly assumptive 3- or 5-year projections that are used to support significant investment asks. It’s no wonder we hate this — we’re staking our professional credibility on these unvalidated assumptions!

The problem is many product managers are never taught a systematic method by which to obtain the crucial information needed to inform a business case.

So what’s the solution?

Let me pause here to say if you’re hoping I have a magic secret for quickly validating a product idea, or if you’re totally married to writing business cases or MRDs, then stop. This post isn’t for you, because:

  • It’s different and requires you to THINK.
  • It’s hard work.
  • It can take some time to get results.

But it works. I’m writing for the 10% who (1) realize that the old ways just don’t work, and (2) are willing to try something different.

(Thanks, Kevin Dewalt, for putting this so well, and forgiving me a little plagiarism!)

The solution is validated learning

The bottom line is spending time writing a big document is a colossal waste of time. Instead, focus on validated learning.

Because any new product idea is based on assumptions, those assumptions need to be validated. This can be achieved by formulating testable falsifiable hypotheses around the riskiest assumptions and rigorously testing these hypotheses.

The process of validation can be outlined in 5 steps. Each step generally follows this meta-pattern:

  • Formulate a testable falsifiable hypothesis.
  • Test the hypothesis.
  • Analyze results and learnings.
  • Decide to pivot or persevere.
  • Repeat.

I’ve used these this process to validate ideas for software products, but I imagine it could be adapted for any product concept. (So give it a try and let me know your results!)

1. Write down your customer hypothesis

Most folks typically start with the solution first. That’s the wrong place to start.

You need to take a step back and think very deliberately about your customer. This is true whether you’re pursuing adding a new component to an existing product or are pursuing a brand new product idea.

Note, by customer I mean your buyer — the individual who will buy your product. Even in B2B, you need to think about the specific individual or persona to whom you will need to sell your solution. That’s your customer.

2. Write down your problem hypothesis

What problems does your idea solve for the customer?

One way to do this is to think about the goal or job the customer is trying to accomplish.

For example: “I believe [customer] has a problem achieving [goal].” Or: “I believe [customer] is trying to accomplish [job], because [desired benefit].”

I typically use my Product CanvasTM to do this, as it allows me in a focused manner to break down the problem domain into discrete problems, and then formulate hypotheses around what I believe to be the top problems that my solution absolutely has to solve for first.

3. Validate your customer/problem hypothesis

Now it’s time to test your hypothesis. You do this by talking to folks you believe meet your target customer demographic.

Be sure to define minimum success criteria. This is the minimum amount of data you will need from the test to justify investing more time, effort or resources into proceeding with the idea.

When you’ve met your minimum success criteria, analyze your data, and decide whether to pivot or persevere.

A pivot is a fundamental change in direction of your business model or product strategy. You face a pivot when your hypothesis has been invalidated (i.e., proven false).

At this early stage, you could expect a pivot in terms of a change to your target problems, your target customer, or both. This may mean going back to step 1 or 2.

However, if the results of your test prove (i.e., validate) your customer/problem hypothesis, you may decide to persevere and move on to step 4.

4. Validate problem/solution fit

Now that you’ve validated your customer/problem fit, you need to test whether your idea is a potentially viable solution to the customer’s problem.

There are many ways to go about this, but nothing really beats creating a visual representation of your envisioned solution in the form of a wireframe or mockup. To keep things simple and minimize work, I look to design a representational screen or flow for each discrete problem identified on my Product Canvas and validated via the previous steps.

The primary goal of this stage is to garner early customers who endorse your solution vision and would be willing to use and pay for an early version of the product.

You’re also looking for directional feedback to identify the “right” handful of features to build for these early customers to prioritize your product development.

Formulate hypotheses around your screens, define your minimum success criteria, then reach back out to the customers you had interviewed earlier and demo the screens to them. Also, try to mix in some new folks who fit your target customer demographic.

When done, just like you did at the end of step 3, analyze your data and decide whether to pivot or persevere. At this stage, you may pivot on the solution, the problem or even the customer.

Or, if you’ve validated your hypothesis, you may have problem/solution fit and can move on to step 5.

5. Validate your solution via an MVP

There are many misconceptions about what constitutes an MVP, and I’ve written about these before.

In short, an MVP is  an actual product that attempts to deliver real value to customers.

It’s “minimum” in the sense that it’s an attempt to deliver the absolute necessary set of features or capabilities needed to solve the customer’s problem for which the customer will pay.

Note that an MVP doesn’t necessarily have to be a software app. It could be a service.

A primary outcome of the previous step is being able to understand your customers’ problems at a granular level, which helps prioritize the initial set of features to build. This drives the definition of your MVP.

Once again, formulate a set of testable hypotheses to ensure you’re continuing to drive your product development based on validated learning. Depending on the complexities of the problem and solution, and the nature of my target customer, I may opt to first demo the MVP before actually delivering it. The results of your MVP test will again determine whether to persevere or pivot.

If you’ve got this far, you’ve validated critical components of your product idea. It doesn’t mean your idea is guaranteed to succeed, but you will have gained a far better understanding of the market opportunity, allowing for a far less assumptive and much more robust business case for your new product idea.

Stand Your Ground

Product people: Stand your ground.

If you’re being pushed by engineering to begin development, threatening you’ll otherwise lose your development resources, but you think there’s still crucial product strategy, product definition or customer development work to be completed, stand your ground.

If you’re being cornered into an arbitrary market launch date that adds an unreasonable level of risk to the product delivery and value proposition, stand your ground.

If you’re being coerced into a software development process, because it’s the latest thing or there are zealots blindly evangelizing its benefits with no real perspective on your customers or business, stand your ground.

If the scrum team is complaining to the CIO or any executive who will listen that you’re not physically present with the scrum team 24/7, and you feel your time is better spent in the marketplace with customers, stand your ground.

If Marketing is pushing for a full court press market launch well before any market assumptions have been validated, and you feel a soft launch is better to de-risk the product strategy, stand your ground.

If Business Development is pushing you to add that one feature that will enable them to close that gajillion dollar deal, and that feature makes no sense for any of your other target customers, stand your ground.

If Sales is pushing you to deliver the product earlier because they arbitrarily made up a delivery date to sell a prospect, stand your ground.

If your CFO is badgering you for budget and ROI estimates well before your product strategy has been validated or you’ve achieved even problem/solution fit, give him or her your estimates, say they’re a 100% guess, are practically guaranteed not to hold up, and you won’t be using them to manage the project. Stand your ground.

If your CEO is forcing you to define your MVP based on his or her own personal vision of the product with no customer validation to inform the product strategy, definition and delivery approach, yes, stand your ground.

This is not to say you should be unreasonable, stubborn or inflexible. Be professional. Be collaborative. Listen to them. Understand their perspective. Address concerns. But if you feel you have a case, if you’ve done your homework and feel confident in your point of view, stand your ground.

And don’t be stupid. Have your facts ready. Have a rational, justifiable case. If you have those and can back up your assumptions, stand your ground.

State your case clearly, coherently, calmly, rationally, respectfully, professionally. Even passionately. Stand your ground.

You may be challenged. Expect it. Stand your ground. You may be overruled. Possibly. So what? You’ll have stated your case. Stand your ground. You may be ridiculed, shouted, screamed or hollered at. Stand your ground. (And ask yourself if you really want to work in such a toxic environment.) They may be upset with you, but they’ll sure as heck will respect you, because you stood your ground.

You are the product owner. Know your product, its value proposition, its business model, your roadmap, and your delivery process. Above all, know your customers. Do that, and you’ve earned the right. So stand your ground.

Because when you stand your ground, you’re standing up for your customers. And, as the product person, that’s your job.

How I Became A Product Manager

By Tony Lizza

My God, I’m going to die here, I thought. Every morning the melodrama played out as I marched into the support department of the company where I worked. I had started out there a couple of years before, and everything was easy and fun. I was learning new things. Two years on, I was burned out. No more learning, no more excitement. Just ringing phones, and angry customers, and impossible deadlines, and my god, I’m going to die here. I didn’t see myself in support for the rest of my career. I found quality assurance and documentation tasks dull, and I knew I didn’t want to keep track of project spreadsheets for the rest of my career, so implementation was out. I was always drawn to the process of creating something new, but I wasn’t an engineer. I felt hosed.

All wasn’t lost, though. Even though I didn’t have a technical degree, I accumulated a lot of technical knowledge. I was able to go to work in the documentation department where I got to work writing training material and use cases for features of a new software product. About a year after that, I took a position in the product department of my company. Here’s what I did that helped me.

1) I was curious

I learned about as much as I could in each of my roles. Product, market, domain, it didn’t matter. My first job was supporting a legacy receivables management software package. In addition to soft skills, I used that opportunity to learn Linux, Bash scripting, and Python, among other skills. Have they all been equally useful in career as a product manager? Not all of them, I admit, but some certainly did.

2) I was helpful

I did everything I could. If the website needed updated copy, I volunteered to write it. If an RFP came in, I volunteered to help with it. I did anything to build my knowledge of the product and the market. As a character in Mad Men said, “This is America. Pick a job and become the person that does it.” But be willing to start small. Approach the product manager or department head, and say that you’re interested in taking on some product work. This might be tough if you’re not a natural gladhander. (I’m certainly not!) But most people are willing to help those who ask for it, and there are plenty of long suffering product departments that would be bowled over by your interest. These things often live and die on the say so of your current supervisor, so make sure he/she approves it first. If your company releases a product, SOMEONE is doing product work, or at least should be. If there’s not a formal department, so much the better. This means that somebody has been taking on product work in addition to his/her own workload, and would probably be glad to give some of it up.

3) I positioned the experience I had

I leveraged my experience in those areas to get into a product management role as a BA. It’s about positioning. If you worked in support, then you have customer empathy. If you were an engineer, then you can speak intelligently about product timelines and feature priorities. If you were in sales, then you know the market and have experience qualifying customers.

Even though I didn’t do this, it helps to get a mentor, either someone at your company, or volunteer with an organization like ProductCamp DC. Communities of interest like these are full of passionate, knowledgeable people who genuinely enjoy helping others. (Full disclosure: I am a volunteer with ProductCamp DC.)

There are plenty of other skills that product managers need. E.g., how to build consensus within an organization, how to interview customers, how to develop a product roadmap, etc. But at the very, very beginning, it came down to those three for me. Not coincidentally, these qualities not only helped me get a product management role, but also have served me well as a product manager. And every day I am learning. And every day I’m excited.

Tony

Tony Lizza is a Product Manager at AARP. He tweets at @tonylizza.

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

Selling An MVP

By John Peltier

The Lean Startup movement led by Eric Ries has put the concept of minimum viable product (MVP) into the current vernacular, and certainly into Shardul’s vocabulary. 🙂 An MVP is generally understood to be a product that has just enough functionality to validate that you’ve found market problems buyers are willing to pay to solve, and that your offering solves the problems effectively enough to capture some of the market. This is an attempt to avoid over-building a solution, and solving problems that buyers don’t actually have.

Conducting a full-scale launch of an MVP can be both rewarding and dangerous.

Fraught with Peril

One area of danger is building an MVP that best fits a segment of the market, but selling the solution to the entire market. Buyers from multiple segments force language into their contracts demanding their most critical features, partially solving problems for multiple segments but delaying fully solving the problem for any segment. This makes it more difficult to get glowing references, since buyers from all market segments perceive gaps for a longer period of time.

Another danger is defining your MVP by the functionality needed to demo, versus the functionality needed to use. Teams may be tempted to defer under-the-hood capabilities until after release, especially when feeling the pressure of time-to-market. This gets you to market faster, but with a product that has known gaps.

As things progress, Sales meets resistance due to needs not met in your MVP, and starts bargaining for delivery promises to win deals. Meanwhile, this can crowd out bandwidth to close the gaps–which represent under-the-hood capabilities all buyers will need. Once you say yes to a few deal-makers, you can’t say yes to any more. This will also strain the relationship with Sales.

One way to adjust is to proactively include fewer big-ticket items on the roadmap, while allocating some percentage of capacity to under-the-hood needs. At some point your estimations won’t line up with reality, though, and you’ll have to escalate something that everyone assumed was already there. The silver lining is that these episodes–often a response to onboarding needs, and sometimes useful in winning an early reference–can be used later as an example of why you need to invest in the engine!

A Focused Solution

On the other hand, selling an MVP delivers revenue at perhaps the earliest possible date.  Prospects who don’t need all the bells and whistles encounter a solution that meets their needs, without having to wait for you to build feature after feature that they don’t need. Early adopters likely wouldn’t wait for you to deliver your solution; it’s much more likely that they purchase another vendor’s solution. The other vendor’s efforts to increase the buyer’s switching costs will then make it difficult for you to get that prospect at a later date.

As early adopters, your first clients get to help you decide which 15% of the hundreds of possible features you actually need to build. While a market is much bigger than a handful of early adopters, some effort towards satisfying their needs is warranted if it can deliver you early references, and especially if the things they need are known needs you’ll have to address at some point in the product’s development.

These benefits carry an important condition: the MVP that you provide must solve the core needs well. Adequate won’t win over prospects with lesser needs, and it won’t convince early adopters to provide glowing references. Prospects will need to be convinced that your solution is already so good, that it’s in their best interest to come along with you for the ride.

Your Turn

Depending on the quality of your execution, the early days of being in the market with an MVP can be both hairy and immensely rewarding. What other benefits or drawbacks do you encounter when going to market with an MVP?

John

John Peltier is an accomplished product manager and marketer working in the growing technology community in Atlanta, Georgia. John shares his passion for product management by organizing ProductCamp Atlanta, and by writing at The PM Vision.  John is most easily contacted on Twitter at @johnpeltier.

Why Product Managers Need To Get Out Of The Office

By Kevin Dewalt

For the past few months I’ve been doing Customer Development on product managers to explore their viability as a customer segment for my new startup, sohelpful.me. I’ve been asking them about their challenges in getting insight to customer problems. I haven’t had a job as a product manager in over 15 years, but if you’ll forgive my naivety, I would like to offer a few observations on how the role of product managers has to change, at least if their employers want to survive the coming onslaught of worldwide competition from startups.

The Best Product Managers are Learning from Entrepreneurs

The management science of entrepreneurship has changed more in the past 5 years than in the previous 500. Through Eric Ries’ Lean Startup movement and best practices like Steve Blank’s Customer Development, we are finally seeing the emergence of repeatable patterns and best practices for mitigating the risks of product failure. Prescient product managers — often former entrepreneurs themselves — are seeing these best practices emerge and looking for ways to bring them into their own organization. Unfortunately, many are describing practical challenges with getting their employers to embrace this change.

No Established Processes for Connecting Product Managers & Customers

Unlike entrepreneurs, product managers are beholden to an organization’s behavior, rules, and roles. These structures often create practical barriers between product managers and the very tedious process of developing problem-solution assumptions and testing them with customers.

Customer Input Filtered by Other Stakeholders

Many are frustrated with what they describe as filtered customer input — often by sales or marketing teams who are focused on the most recent customer conversation. They recognize the importance of this feedback,  but feel that it needs to be considered in a larger strategic context.

Overwhelmed with “Inside the Office”

Product managers tend to be multi-skilled, dynamic people — those who are already overwhelmed trying to get an organization to execute. Many describe themselves as spending way too much time focused on day-to-day fires or “project management”.

Your Employers Need to Wake Up: The World Wants Your Customers!

Forget Silicon Valley. Through my free startup help sessions, I’m giving advice to entrepreneurs worldwide – Beijing, Bangalore, Singapore and Manila. They’re often 3-5 person teams trying to build highly customized solutions to micro-segments of your customer base — for a lot less. At least 50% of my discussions are about doing Customer Development on the American market. Their biggest challenge is “getting out of the office” — talking to customers to get insights. They’ve read Ash Maury’s Running LeanEric Ries’ The Lean StartupJeff Gothelf’s Lean UX, and watched Steve Blank’s (free) Udacity CourseI try to help them find your customers to get better insight using lower-cost techniques like recruiting them over Craigslist for problem-solution interviews. For the moment, your employer has some practical advantages over these new competitors – language, time zone, trust, experience, and relationships. In the long run it won’t be enough if your employers don’t wake up to the reality that your job has to change. But, alas, they probably won’t change. Most likely you’ll realize it before they do, but by that time you’ll already be gone — you”ll be “getting out of the office” building your products in your startup. Perhaps after they acquire your startup — for 1,000x your salary — they’ll listen.

Kevin

Kevin Dewalt is an American entrepreneur & investor currently living in Beijing, China. He writes about his experiences building products at his blog and on Twitter.