Tag Archives: Product Management

5 Indispensable Habits Of Great Product Leaders

As a product management leader, there are many demands on your time. It’s easy to get sucked into working on the most pressing issues and on meeting other people’s expectations.

As “do-ers”, it’s in our nature to jump on these issues immediately. We pride ourselves on our competence to tackle these right away.

But when we do so, are we as product leaders really making traction on the things that matter? When you get to the end of the day, do you feel a sense of accomplishment?

We’re all familiar with the Eisenhower Decision Matrix:

Eisenhower Decision Matrix

Eisenhower Decision Matrix popularized in the self-help book “First Things First” by Stephen Covey

We know we should be spending more (most) of our time in quadrant 2, the yellow box.

I must admit, though, I’ve been guilty of spending too much time in the urgent column. Heck, I’ve wasted time being in quadrant 4.

There’s always a fire to put out, an urgent meeting, a request from up the chain to satisfy, someone stopping by the desk to ask a “quick question”, an email to answer, a phone call to return.

The problem is that while it feels like we’re getting stuff done in the moment, we’re actually not getting anything of real value done. It’s an illusion.

And we know this, because by the end of a day like this we usually feel drained, and lack a sense of real accomplishment.

This problem can be particularly acute for product leaders, who are responsible for (among other things) the product vision and strategy of the company, the business results of the company’s product portfolio, the performance of the product management process, and the success of their team.

The challenge is if we don’t make time for the important stuff, the urgent will always win.

But it’s easy to say we should spend time in quadrant 2. How do we actually do that?

Dan Martell, successful serial entrepreneur and investor, published this video on his YouTube channel in which he talks about what should the day of a startup CEO look like.

He talks about how as he grew in his career, he began thinking about how he could make time for the things important to him, and what are the things other people can support him on and help him with.

He lays out 5 things that startup CEOs should focus on. As I listened to this list, I realized that these same habits apply to successful product management leaders!

They’re habits because they do these regularly, every week, every day. It’s how they ensure they’re making traction on the things that are most important.

As I’ve grown in my own career, I’ve done these same things, and found them to be indispensable in the successful execution of my products.

Here they are:

1. The Daily Check-In

The most effective product leaders check in with their team every day.

Yes, every day. As much as is practical, do this at the top of the day.

One way may be in the form of a stand-up or huddle where folks provide a quick update on progress and highlight any major impediments to getting work accomplished.

Another way is to check in individually. You may “walk the floor”, stopping by each team member’s desk for a few minutes to see how things are going, how they’re feeling, and if there any major issues they may need help with.

As a product leader, you need to stay in tune with the “pulse” of your team. A daily check-in will enable you to stay on top of things tactically, as well as ensure you’ve got the temperature of your team members.

2. Keep Half Your Schedule Open For Strategic Stuff

What? Half? Really?

OK, so this one may be a challenge. But it’s SUPER important.

As a product leader, you’re responsible for setting the product vision and strategy.

That means spending time doing research, discovery and analysis, AND having some thinking time.

In addition, as a product leader, you’re responsible for communicating the product vision and strategy to everyone else in the organization.

So the point here is you need to keep a good chunk of time dedicated toward strategic activities.

If you think this is difficult, look back at the Eisenhower Decision Matrix, and ask yourself how you realistically plan to get quadrant 2 stuff done?

If you don’t make time for it, if you don’t protect that time, trust me, you’ll never get it done.

I’ve actually blocked time off on my calendar to do strategic stuff. I fight not to give up that time.

Keep half your schedule open for strategic stuff.

3. Major Projects Should Be On Your Calendar

This is somewhat related to point #2.

For example, you may be performing due diligence on a potential partner or acquisition as part of a developing product strategy. Or you may be conducting some market research or customer interviews.

Make sure these things are on your calendar.

In addition, there may be major initiatives either you are personally championing or that your team is working on that require your priority attention. A new product launch or a major release, for example.

If you want to get traction on these things, be sure to block off a reasonable amount of time for them — time that enables you to achieve flow.

4. Align Everyday Work To The Product Vision

In product management, it’s easy to get consumed by a particular feature, requirement, story, page layout, design construct, thorny technical issue, project delivery date, PowerPoint slide, or Excel analysis.

As a product leader, you need to make sure everyone understands their work serves a higher purpose.

That it ties back to something bigger, a shared goal. This is typically the product vision, product strategy, even the company mission.

And you need to do this constantly. All the time. Every day.

As Dan Martell describes it perfectly in his video:

“People forget. They get in these funks. They don’t understand why what they’re working on is going to be aligning to the bigger purpose. You should be going around to your team and saying, ‘Hey, you know that interface you’re designing? That’s going to allow us to do X, Y and Z, and allow us to achieve these big results we’re all agreed upon.'”

5. Talk With Customers. Every Week.

If you’re a product leader, this should be a “Duh!”

In fairness, though, it’s easy to become preoccupied with the demands of senior executives, the CEO, the Board, your peers, and your own team.

Certainly, the larger the organization, the more demands on your time from people within the organization than without.

But the primary job of product management is an executable product strategy. To do that means spending time with customers.

So it’s imperative product leaders dedicate time to hear directly from their customers.

Even if you have product managers reporting into you, perhaps an entire hierarchy with Directors, Senior Product Managers, Product Owners, etc. on your team, you need to spend time with your customers.

Not so much to get feedback on a specific feature or an interface design, but to immerse yourself in their world — what challenges they’re facing, what trends they’re seeing in their industry, what opportunities they’re pursuing, what defines business and personal success for them.

By doing this, you can not only make sure the current product vision and strategy, even the company mission, is aligned with the needs of your customers, but also identify opportunities to pivot on these things if necessary.

And it enables you to align the every day work with how you’re creating value for your customers.

Disclosure: I don’t know Dan Martell personally, but am a follower. All credit and many thanks for his excellent video in inspiring this post.

Create Your Business Case Using Customer Development

The traditional product innovation process of writing a business case with long-term financial projections, then writing a big PRD, then doing development and launch your product doesn’t work.

At the 2015 Modev MVP and the Lean+Agile DC conferences, I presented an actual example of using Customer Development and Validated Learning to test a new product idea and build its business case, which produced far more impactful results.

Here my slides from those talks (same set used for both):

 

How To Get Quality Customer Insights (Spoiler: It’s Not About Time)

A Sales Exec and I were debating whether amount of time spent with a customer is a measure of the quality of the customer interaction.

His argument:

Just curious — do you see 23 touches for 5 mins the same as 23 touches for 1 hour each — I think it is different and material.

From my perspective, I need to allocated a certain number of hours per week with customers, and believe that number in a normal week is likely 5 hours. I am not sure if that is right, but 5 hours out of 40 per se seems about right. To me, a 3-hour dinner with a customer will be very revealing.

Time matters… Speaks to quality, don’t you think?

His assumption here is that there’s no meaningful insight to be gained in a 5-minute conversation. He’s also arbitrarily picked 5 hours per week. (Why not 4? Or 2? Or 8?)

My response:

Here’s how we should think about it.

Why are we seeking VOC? What’s the purpose?

At the most fundamental level, in any situation, there are three kinds of customer insights we’re trying to gain:

  • Problem Discovery
  • Problem Hypothesis Testing
  • Solution Hypothesis Testing

There are many techniques to accomplishing these. The specific ones we use depends on the situation.

For problem discovery, a series of 1-on-1 interviews is best. These take time. 45-60 minutes an interview across 10, 20, 50 customers, for example.

For hypothesis testing a broad problem domain, again, 1:1 interviews may be best to start with.

So in this case, I’ll opt for 23 phone conversations of 30-60 mins each, because I know neither email nor a survey nor a 5-min phone conversation will provide me the richness of insight I need.

For solution hypothesis testing, it can vary.

If I’m validating a mockup of a potential solution the customer has never seen before, a 20-60 min interview may be needed.

In all the above situations, I want the richness of the fluidity of the conversation, have an opportunity to ask follow-up questions, and feel the customer’s emotional responses.

But let’s say I’m trying to validate the need or usefulness of a specific feature — i.e., will it or does it solve a specific, previously identified customer problem.

In this case, using an email or an automated tool would enable 23 touches in 5 minutes, and work perfectly. I could do it via phone calls, which would have taken longer, but ultimately would have given me the same quality of insight.

Another example is having weekly meetings with the Sales team.

The meeting doesn’t preclude the opportunity for a Product Manager to get on sales calls and demos. However, there’s great efficiency and value to these meetings, because in 30 mins I get buyer feedback across all our products from 9-10 folks who are making a large number of customer calls every day.

Which technique to use in any given situation depends on the type of VOC one is seeking, the purpose of seeking it, ability to access the customer quickly, the time available to seek and act on it, and of course reasonable judgment.

With respect to allocating time for yourself to obtain VOC, that’s a different thing.

You’re a busy person, so it’s perfectly reasonable you need to figure out how much time to allocate for VOC vs. other tasks.

But that’s solving your problem — your problem of time allocation.

It’s different than the how, what and why of obtaining the VOC itself.

And provides no guarantee of the quality of customer insight that you may gain.

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 last weekend’s ProductCamp DC event, my co-founder and I hosted a session called “Tales From The Product Frontlines”. Our first topic was about this very scenario, and it so energized the participants that it took up 30 of the 45 minutes we had been allotted!

During the session, we asked product people 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, and 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.

Why is this? Because 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 we were 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 I’m telling the truth (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

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, which is 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 truly new product.

Note, by customer I mean the individual who will buy your product. Even in B2B, you need to think about the specific individual or set of individuals 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 the 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 a minimum success criteria, which 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 ideally 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.

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.

Using Customer Development To Create The Business Case For Your Product Idea

Many of my product help calls are from folks frustrated with being able to pursue a new product in an existing company.

They complain about how difficult it is to secure resources and garner internal stakeholder buy-in.

If you find yourself in this position, congratulations!

As painful and frustrating as it is, many successful product people I’ve met have gone through exactly what you’re experiencing — including me!

The problem is the way we’ve been taught to pursue this — to first write a business case, business plan or MRD — just doesn’t work. The fact is, people think writing a business case is a waste of time and hate it.

And no where are we taught how to cultivate stakeholder support.

Like it or not, every project in an existing company, regardless of the size of the company, needs an internal champion or sponsor.

Lack of stakeholder buy-in can be the biggest impediment to your product no matter how good your product idea may be.

So it’s no surprise really that product people are frustrated.

 

So here’s a new process I’ve been following that’s worked much better for me:

Using Customer Development To Create The Business Case For My Product Idea

In a nutshell, I deferred asking for major dollars and resources until I absolutely needed to. I used a series of validated learning milestones to build momentum internally and to build the case for investing in my product idea.

Here’s what I did:

1. I quickly sketched out my product strategy on a 1-page Product Canvas. No wasting time writing a multi-page document no one is going to read.

2. I decomposed the product strategy into critical learning milestones meant to answer the most important questions in my product strategy:

  • How does our target customer describe the problem?
  • How are they solving it today?
  • Why is that solution not working for them? In other words, why is the problem still a pain for them?
  • How can we know before we invest a lot in development, sales and marketing that the solution we’re thinking of building really solves the problem?
  • How quickly can we get our first customer?
  • What are the most important features we need to have in our go-to-market product?

3. I figured out what’s the least amount of work I need to do to maximize my learning for each milestone.

4. I broke down my investment need into these milestones, showing how ROI could be tangibly achieved based on measurable results.

Here’s what the investment plan looked like:

validation_workflow

In the past, I would have asked to spend money on 3rd party market research (four to five figures), a design agency to craft the user experience (five to six figures — ugh!), a usability study (five figures), and a large development team (many figures).

This would be costly and take a long time before I would have delivered the product to a single customer.

And it’s a tough business case to make.

Instead, because I had broken down the plan into these learning milestones, I was able to easily accomplish the first two milestones by spending little to no money at all.

The first was simply my time, so required no money.

To validate our solution hypothesis, I used Balsamiq to sketch a handful of the key screens of our solution. Total cost was $79 for the tool and my time.

When we were ready to design the user experience, since we didn’t have an in-house designer, we commissioned a cracker-jack freelance designer — way cheaper than hiring an expensive design agency, and way faster. It got the job done.

(If you happen to have an in-house designer or design team, awesome — use them. Your investment “ask” may only be some of their time.)

In this way, I was able to use the resources I had at my disposal for as long as I could to create traction.

This approach not only allowed me to conserve precious funds and resources, but also allowed me to be less assumptive and more data-driven in identifying my investment ask at subsequent stages.

It also enabled me to not only build early traction with customers, but also have them help me define the minimum feature set we’d need to develop to go to market — labeled as the Minimum Sellable Product (MSP) in the picture above.

Here are the benefits that resulted:

  • Instead of writing a massive business case based largely on guesswork, I needed only to sell a bunch of mini-business cases. Way quicker and easier to do.
  • Each mini-business case was informed by the learnings from the previous stage, making each subsequent mini-business case better informed, more robust, and an easier sell.
  • The product strategy was informed by real market insights. (What a product manager needs to do anyway!)
  • I had a customer driven product roadmap that was tough for anyone to dispute as it was informed directly by tangible customer insights, which defined what went in our MVP vs. MSP vs. roadmap vs. nice-to-have.
  • This enabled our product development efforts to be more focused, as I had all the ammunition I needed to fend off arbitrary new feature requests that risked derailing our product development.
  • Because of our “co-innovation” approach with our customers, we were able to get “earlyvangelists” that we could leverage to generate momentum for our broader market launch. Customer Development in concert with Product Development!
  • All of this made it much easier for me to garner, maintain and accelerate buy-in from my internal stakeholders, because:
    1. My plan showed a clear milestone-based investment plan with the ROI to be gained at each phase.
    2. Smaller continual investments are easier to digest and support than a large upfront one.
    3. Each investment stage was grounded in real customer data, increasing confidence in pursuing the product.
    4. My stakeholders felt involved in the process, as I made sure to keep them informed and provide them an opportunity to provide feedback.
    5. This, in turn, kept me one step ahead of any potential concerns they may have had, and I could make sure to address them at a future stage.

The Dirty Dozen Product Roadmap Roadblocks

In my last post on defining an MVP in corporate innovation, I talked about how best practices in garnering stakeholder buy-in for product roadmaps espoused by Bruce McCarthy can be used as a framework for the same when defining an MVP in an “internal” startup product. Here, with permission, is a re-post of his excellent post on the the “Dirty Dozen” product roadmap roadblocks, and in a way, they seem applicable to internal startup products as well.

By Bruce McCarthy

A good product roadmap is one of the most important and influential documents an organization can develop, publish and continuously update. It’s the one document that steers the entire organization in delivering on the company strategy.

It’s key to success, and yet many organizations struggle to produce effective roadmaps. In fact, many organizations don’t create one, even to publish internally. Or they do, but it is simply a collection of unrelated features and dates.

What Is A Product Roadmap?

A roadmap is your vision for how a product (or product line) will help achieve your organization’s strategic goals. In that sense, it is literally a map of the steps involved in getting your business where you want it to go. To make it even more concrete, I also like to think of a product roadmap as a timeline view of your priorities.

A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.

A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.

The Dirty Dozen

In my experience, though, there are some specific areas where companies commonly break down in developing roadmaps, hitting roadblocks that often keep them from getting where they want to go. I call these roadmap roadblocks the “Dirty Dozen.”

1. No Strategic Goals

If a roadmap is the path toward your goals, you obviously need to set those goals before you start. Yet many companies fail to sit down and explicitly describe the destination they are driving toward.

Is your product roadmap aligned with your strategic goals? Have a conversation with your CEO or another exec in the know. It may clarify a lot of your prioritization dilemmas.

2. Focusing on Features

A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team. A roadmap should make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.

Look at your roadmap from the point of view of a board member or a customer. Would they see their interests reflected?

3. Inside-Out Thinking

Focusing on features can be a symptom of failing to understand your market. Yes, priorities should be driven by internal goals, but those goals must also respond to market reality.

Ask yourself whether your roadmap priorities are driven by the needs of the people and organizations you intend to serve. Strive to bring that message from the outside in.

4. One Size Fits All

You probably serve more than one market segment. When you are talking to customers or partners in one segment, the roadmap you show should focus on how you will address their needs.

Make sure your roadmap is not one-size-fits-all. If a customer sees their interests in only 1 of the next 6 releases, they’ll get the message that you are not focused on them.

5. Trying Too Hard to Please

That said, many roadmaps are simply lists of customer requests prioritized by number (or size) of customers requesting or voting for the feature. This may help with retention for a while, but will not drive your company into new markets or to invent anything new.

Rather than just taking requests, listening for unsolved problems in your market (and doing something about them) is the best way to avoid a roadmap that’s really just a popularity contest.

6. Playing Catch-up

It’s often a mistake to focus on matching your competition feature-for-feature. All this does is commoditize your market. Instead, focus on creating unique value by developing solutions your competition can’t easily duplicate.

How many items on your roadmap are “me too” features designed to close perceived competitive gaps? How many of those have actually lost you business?

7. Not Getting Buy-in

The best-conceived roadmap won’t get you where you need to go if you can’t get anyone else to come along for the ride. You’ve got to get your development, sales, marketing, finance and other stakeholders involved early so it becomes their plan, not just yours.

If people use words like “intellectual,” “cerebral,” “theoretical,” or “ivory tower” to describe you or your work, this is code for lack of buy-in.

8. Prioritizing on Instinct

Good product people develop good instincts for their market. As a company grows, though, it’s hard to get the buy-in you need from all players based just on your instincts.

Can you tie everything on your roadmap back to your strategic goals? Can you show the ROI calculations that put priority 1 ahead of priority 2? A little data settles a lot of arguments.

9. Being Too Agile

Agile was developed as a response to lack of consistent direction from business execs. That doesn’t mean it’s incompatible with good direction. Yet many companies fear to map out a course thinking it’s not allowed in Agile.

Don’t let being agile become an excuse for indecision. You may choose to adjust course down the road, but you’ll move a lot faster if you first take your best guess at a destination.

10. Being Too Secretive

Some organizations have a roadmap but shy away from sharing it with anyone. It might be fear of revenue recognition issues, lack of confidence in the company’s direction, or just not wanting to look foolish if things change.

A good roadmap is not a contract. It can and should be designed as a statement of direction and intent, but customers and investors expect you to accept and act on feedback from the market. They expect your roadmap to change, so stop worrying.

11. No Buffer

One reason an organization might be reluctant to share is if their roadmap is too detailed. A roadmap consisting of 40 bulleted features in each of 10 precisely-dated releases is impossible to read, and can really constrain your options for adjusting course down the road.

Your roadmap should consist of problem-solving themes and broad time-frames. This gives you the leeway to cut or defer a specific feature without risking on-time arrival at your destination.

12. Over- or Underestimating

ROI is a critical consideration in prioritization, yet many product teams make the mistake of setting business priorities without considering development costs. Conversely, some teams spend months estimating every possible product initiative without first considering which are likely to be worth the time.

Approach your technical partner for a quick, high-level estimate of the work involved in your 10 most wanted. What if #4 turns out to be trivially easy compared to the 3 ahead of it? Wouldn’t you like to know that up front?

AN INVITATION

If your organization’s progress toward its strategic goals is slowed by any of these roadmap roadblocks, feel free to set up a time to chat with me during my free office hours. You may also be interested my hugely popular roadmapping presentation from ProductCamp Boston, or in Reqqsthe smart roadmap tool for product people.

Use your product powers for good.

Bruce McCarthy is a serial entrepreneur, 20-year product person, and sought-after speaker on roadmapping and prioritization. He is Founder and Chief Product Person for UpUp Labs, where he and his team are at work on Reqqs, the smart roadmap tool for product people.

Original article can be found here.

An MVP Is Not The Smallest Collection Of Features You Can Deliver

Source: Spotify

Source: Spotify

There’s a lot of discussion and confusion about what is and isn’t a minimum viable product (MVP).

Worse, many execs have latched on to the term without really understanding what truly constitutes an MVP — many use it as a buzzword, and as a synonym to mean a completed version 1.0 ready to be sold to all customers.

Buzzwords are meaningless. They represent lazy thinking. And using “MVP” to mean “first market launch” or “first customer ship” means you’re back to the old waterfall, traditional project-driven software development, sales-focused approach. If that’s your approach, fine. Just don’t call what you’re delivering an MVP.

On the flip side, lots of folks in the enterprise world, including in product management, over-think the term. It gets lost in the clever nuances of market maturity, and a long entrenchment in the world of release dates and feature-based requirements thinking.

Many folks think of MVP as simply the smallest collection of features to deliver to customers. Wrong. It’s not.

The problem with that approach is it assumes we know ahead of time exactly what will satisfy customers. Even if we’ve served them for years, odds are when it comes to a new product or feature, we don’t.

Now, the challenge with the concept of a minimum viable product is it constitutes an entirely different way of thinking about our approach to product development.

It’s not about product delivery actually — in other words, it’s not about delivering product for the sake of delivering it or to hit a deadline.

An MVP is about validated learning.

As such, it puts customers’ problems squarely at the center, not our solution.

Reality check: Customers don’t care about your solution. They care about their problems. Your solution, while interesting, is irrelevant.

So if we’re going to use the term “MVP”, it’s important to understand what it really means.

Fortunately, all it takes to do that is to go back to the definition.


Download The Handy Primer “What Is An MVP?” >>


Minimum Viable Product (MVP) is a term coined by Eric Ries as part of his Lean Startup methodology, which lays out a framework for pursuing a startup in particular, and product innovation more generally. This means we need to understand the methodology of Lean Startup to have the right context for using terms like “MVP”. (Just like we shouldn’t use “product backlog” from Agile as a synonym for “dumping ground for all possible feature ideas”.)

Eric lays out a definition for what is an MVP:

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Eric goes on to explain exactly what he means (emphasis mine):

MVP, despite the name, is not about creating minimal products… In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Second, the definition’s use of the words maximum and minimum means an MVP is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Let’s break this down.

1. An MVP is a product. This means it must be something delivered to customers that they can use.

There’s a lot that’s been written about creating landing pages, mockups, prototypes, doing smoke tests, etc., and considering them as forms of MVPs. While these are undoubtedly worthwhile, and certainly “lean”, efforts to gain valuable learnings, they are not products. Read Ramli John‘s excellent post on “A Landing Page Is NOT A Minimum Viable Product“.

A product must attempt to deliver real value to customers. So a minimum viable product is an attempt — an experiment — to deliver real value to customer.

Which leads us to…

2. An MVP is viable. This means it must try to tangibly solve real world and urgent problems faced by your target customers. An MVP must attempt to deliver value.

So it’s not about figuring out the smallest collection of features. It’s about making sure we’ve understood our customers’ top problems, and figuring out how to deliver a solution to those problems in a way that early customers are willing to “pay” for. (“Pay” in quotes as it depends on your business model.)

If we can’t viably solve early customers’ primary problems, everything else is moot. That is why an MVP is about validated learning.

3. An MVP is the minimum version of your product vision. A few years ago, I had to build an online form builder app that would allow customers to create online payment forms without the need to write any HTML or worry about connecting to a payment gateway. Before having our developers write a single line of code to build the product, we first offered customers the capability as a service: we would get their specs, and then manually build and deliver each online payment form one-by-one, customer-by-customer. Customers would pay us for this service.

This “concierge” type service was our MVP version of our product vision. Of course, it wasn’t scalable. But we learned a heck of a lot: most common types of payment forms they wanted, what was most important to them in a form, frequency of wanting to make changes, reporting needs, and how they perceived the value of the service.

We parlayed these learnings into developing the software app itself — which, by the way, we delivered as an MVP to early customers to whom we had pre-sold the software product. (Yes, we delivered two different types of MVPs!)

Whether you take a “concierge” approach or your MVP is actual code, it most definitely does NOT mean it’s a half-baked or buggy product. (Remember viable from above?)

It DOES mean critically thinking through the absolute necessary features your product will need day 1 to solve your early customers’ top problems, focusing on delivering those first, and putting everything else on the backlog for the time being. It also means being very deliberate about finding those “earlyvangelists” that Steve Blank always talks about.

Ultimately, the key here is “maximum amount of validated learning”. This means being systematic about identifying your riskiest assumptions, formulating testable falsifiable hypotheses around these, and using an MVP — a minimum viable product version of your product vision — to prove or disprove your hypotheses.

Now, validated learning can certainly be accomplished via a landing page, mockup, wireframes, etc. And it may make sense to do these things. Super. But don’t call them MVPs, because while they may deliver value to you and your product idea, they’re not delivering actual value to the customer.

At the same time, the traditional product management exercise of identifying all the features of a product, force ranking them, and then drawing a line through the list to identify the smallest collection to be delivered by a given timeframe is not an MVP. Why? Because this approach is not predicated on maximizing validated learning. If you’re going to pursue this approach, go ahead and call it Release 1.0, Version 1.0, “Beta”, whatever. But don’t call it an MVP.

An MVP is about not just the solution we’re delivering, but also the approach. The key is maximizing validated learning.

I’ve created a handy primer on what is a minimum viable product. Download it below. I hope it helps you to become a pro at defining an MVP for your next great product idea!


Download The Handy Primer “What Is An MVP?” >>


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.

Introducing Product Management into your company – part 2

In part 1, I talked about the challenges of introducing product management into an established organization. Here I share hard-learned lessons on how to avoid common pitfalls and start laying the foundation for long-term success.

Start with why

If you’re looking to bring Product Management into your organization, start with this very fundamental question:

Why?

Seriously, why do you really need product management? What problem are you expecting it to solve?

Improved product development processes?

Better requirements writing? (Ick.)

Maintaining feature lists? (C’mon, seriously?)

Being the demo guy? (Groan…)

Project manage software releases? (Get a project manager.)

Some folks believe dedicated Product Management is needed because there needs to be someone to coordinate all product related activities across the organization — in other words, serve as a glorified air traffic control.

While there is certainly a degree of this involved in product management, you don’t need a dedicated Product Management department just to coordinate your organization’s inefficiencies around your product.

Those inefficiencies could be solved by your various departments better coordinating around product activities. Or they could be re-structured and appropriate processes could be developed around them to ensure continuous delivery.

The ‘why’ question is critical because it sets the expectation for the value Product Management is expected to bring to the organization.

It also crystallizes whether there are ways to solve the problems the organization faces through its current structure.

So why would you want Product Management?

Because you fundamentally understand that sustainable growth comes from innovation…

Tha innovation is about creating monetizable customer value

And product management is the chief vehicle to deliver that.

So if you’re hiring a product manager because you’re developing a software and simply need someone to provide requirements to engineering and project manage the delivery, don’t hire a product manager. Hire a project manager who can double up as a business systems analyst.

Prepare the organization

You must understand that Product Management is a disruptive force, a radical change to the way the organization has been conducting its business thus far. The introduction of a product management function will centralize many functions that were previously diversified. (Fragmented?) Senior leadership MUST think carefully if this is something they want to take the organization through and must prepare to shepherd each of the other departments through their change curves.

In other words, ssenior leadership must take an active role in the success of product management.

Who’s your first hire? And where do they sit?

A more senior individual will bring the experience and know-how to take on a more leadership type role, coalesce the organizations around a coherent product strategy and, when the time comes, leverage their personal network to bring in additional product management talent.

For a growing company, taking over many of the product strategy execution aspects off of the CEO, CIO/CTO, founder, etc. is exactly what the first formal Product Management leader would do. As such, you’ll be better off making your first hire at a more senior level, at least VP or Director. Ensuring sustainable success for the position — and, thus, for the product strategy — in an ideal manner means setting it up in terms of stature and position with respect to the other departments.

A common pushback I hear from organizations that have never hired a product manager is they worry a more senior person may not be willing to be as “hands on” and handle the necessary tactical activities that need to be done.

First, that’s silly, frankly. Just make sure in your hiring process you look for a leader who’s willing to and has demonstrable experience getting their hands dirty.

Second, product management is a unique discipline that necessarily requires one to execute tactically while thinking strategically. It’s the thing that sets it apart from many other disciplines.

Now, as a practical matter, it’s possible the company may simply not have the budget to hire a senior level person since such an individual will naturally command a higher compensation. And waiting to have the right budget may not be an option if the company is in crisis mode where it needs someone to step in to pick up activities that are getting dropped. So the company may be forced to opt for a more ‘junior’ product manager.

Regardless of the experience level of the individual and the title of the role, one of the biggest risks here is where to place this individual in the organization. I would still advocate having this person report directly to the senior most executive in charge of product strategy, including the CEO.

Unfortunately, what often happens is the individual is put under Marketing, Sales or Engineering. (Or, worse, “IT”.) The dangers with this approach are well documented.1

The product manager becomes a support role for the primary function of that department, providing content for marketing materials, doing product demos for sales, or writing requirements and project managing deliverables for engineering. No time to do the critical work of understanding market problems and formulating the product strategy.

Who to hire and where they sit are critical decisions to ensure long term success. I once worked for a company that rotated through five directors and seventeen product managers in just six years. A total of twenty-two. Twenty-two!

Ensure senior sponsorship

Ensure there is someone in a senior executive position who is willing to be the champion for Product Management. This has the greatest impact on Product Management’s long-term success.

You need someone at that level to evangelize the value that product management brings to the organization, and provide the necessary air support when political attacks threaten to disrupt it in its formative stages.

Do you feel lucky? Well… do ya?

So far I’ve talked from the organization’s point of view. What if you’re the first product manager in the company?

Here’s what you should do:

Clarify your role

Because expectations may vary widely, it’s important to clarify your role upfront.

If you’re joining a startup, an enterprise with a visionary CEO, or a company with established lines of business, the CEO or line of business may want to continue to act as the product visionary and retain control over the product direction.

In this case, the Product Manager will likely play a more tactical role, working more closely with engineering on product releases, perhaps supporting marketing and sales activities. Your role with respect to setting the product strategy will be strictly as an influencer.

This may be okay if you’re a newly minted product manager or have got only a few years of PM experience under your belt. Your gaps are in understanding the business, the industry, and the go-to-market strategy. If your company is selling to other businesses, you may have gaps in understanding your customers’ business models.

You can reasonably expect to be coached and mentored with respect to these gaps so that over time you can take over more of the go-to-market and strategic aspects of the job.

And if you are the visionary CEO or line of business GM hiring the product manager, you should prepare yourself to mentor your newly hired product manager over the next several years.

Clarify expectations

You need to have a mutually agreed upon definition of success. Clarify how your performance will be judged. Reconcile these with the scope of the role.

If you’re expected to play a more tactical role, yet deliver product innovation…

Or if you’re measured on the number of defects and customer complaints; yet the role is about market insight and setting the product direction…

Or you’re told they want you to be strategic, but you’ll be measured on tactical things like “on-time” delivery…

These are signs of expectations being incongruous with the role.

Or to put it more bluntly: The role is set up for failure and you should RUN AWAY.

As stated earlier, Product Management is an agent of change, because it changes existing business processes, and takes decision making and responsibilities away from current owners. This creates uncertainty.

To the extent reasonable, talk to everyone. Understand their expectations. Share these findings with your hiring bosses to clarify expectations and the role, and ensure they are congruous. Doing this has the added benefit of helping you establish key relationships and building your credibility. (Important!)

Ensure senior sponsorship

I talked above this above. Regardless of whether you’re coming in with the title of “Product Manager” or “VP or Product”, make sure there is a true believer at the senior executive level who will go to bat for you, give you the space to establish yourself into the role, and support your efforts to be targeted and focused.

Which brings us to:

Focus!

Look, you simply can’t do everything. If you’ve done your homework on the role and expectations fronts, identify what you think are the most pressing problems, share them with your stakeholders, gain their buy-in, and focus relentlessly on the top priorities.

Lower level priorities and new problems will crop up, of course, but at least you’ll be able to fall back on the agreement you reached and have a constructive conversation on re-assessing priorities based on new realities. This gives you a much greater chance to get things done while keeping your credibility intact.

Introducing Product Management into an organization can be fraught with ambiguity, unreasonable expectations, and threats from every corner. But with foresight and planning, it’s possible to set it up for long-term success. Either way, it’s going to be a roller coaster. So saddle up, buckle in, and get ready for a wild ride!

1Further reading:
Marty Cagan: Where Should Product Management Live?
Steve Johnson: Where Does Product Management Belong In An Organization?
Rich Mironov: Where Should PM Report?

Introducing Product Management into your company

If you’re considering introducing product management into your organization, or are the first product management employee hired into a company, then tread carefully! Having done this more times than I care to recall, I can attest there are fewer professional situations more fraught with ambiguity, unreasonable expectations, threats from every corner, and high likelihood of failure for the Product Manager and the organization.

Why would a successful business decide to introduce product management into its organization at all?

In one company I had joined, the business had been extremely successful selling variations of essentially the same product for years and years. But with potential new business drying up, the execs decided the company needed to be more “innovative”, and their answer was to create a Product Management department.

Other reasons could be:

  • With everyone in the company focused on marketing, selling, customer service, managing operations, hiring, and a hundred other things, the organization finds no one is focused on growing the product portfolio.
  • OR… the product portfolio may have grown like wild fire, and now there are multiple versions of the product, causing customer confusion and inefficiencies within the organization. Time to consolidate.
  • The product has become so “feature rich” that sales and marketing no longer know how to position the product to customers, customers cannot be serviced efficiently, and delivery dates keep slipping as each additional piece of functionality adds exponential risk to development and testing.
  • A services company is trying to become a product-focused one, and after lots of wasted time and money realizes they need product management.

For any of these reasons, the company executives decide its time to bring in product management.

Buyer Beware

Although these situations may seem ideal to introduce product management, they abound with pitfalls for the unaware. It’s important for both company execs and Product Management to be mindful of numerous land mines:

Unfounded unreasonably high expectations. Product Management is suddenly looked upon as the silver bullet answer to all the company’s problems.

Not all expectations are created equal. Expectations are also different across each department:

  • Engineering/IT expects Product Management to write requirements, ensure zero scope changes, project manage the delivery, conduct UAT, manage defect resolution, and make seamless release go/no go calls.
  • Sales expects Product Management to be available for every sales call, produce sales collateral, do product demos, commit to product features that will help them close the next big deal with a guarantee to have them all available by the date they already promised to the client.
  • Marketing expects Product Management to provide the content for marketing materials or, worse, wants nothing at all to do with Product Management.
  • Execs expect Product Management to come up with the “next big thing”, have a solid business case behind it, deliver it “on time”, and ensure it makes a ton of money.

What does Product Management do? Most times folks don’t understand the role of Product Management and the value it brings to the organization. Let’s see…

  • Salespeople close deals.
  • Marketing runs campaigns, advertising, promotions, and events.
  • Account Management / Customer Success manages client relationships.
  • Operations manages business processes.
  • Customer Service runs the call center.
  • IT takes care of “all that technical stuff” the rest of the organization would rather not be bothered about.

Pretty straightforward. So what exactly does Product Management do?

And here’s the fun part: even the executives of the company — the same folks who decided to introduce Product Management — may not be clear on what exactly it does or how to measure its value!

Why do we even need Product Management? Infinitely worse is when folks secretly question the decision to bring in product management. This is often more prevalent at the department level than the executive level.

The thinking goes this way: “We’ve been successful all these years without it, so why do we need it now?”

Product Management represents a disruption to tradition and the status quo. And so, it can be seen as a threat. We humans typically don’t embrace change so readily. In one company, IT had historically written the business requirements and Sales always went directly to IT and so was more than happy with this arrangement. When Product Management came into the picture, the battle lines were drawn!

The scapegoat syndrome: A common way for other departments to deal with the perceived threat is simply to blame Product Management for anything and everything wrong with the product.

Suddenly Product Management is getting blamed for deals not getting closed, because the product does not have the features desired by the last “hot” prospect.

If the product has holes, Product Management is called to task for writing poor requirements.

If customers don’t respond to marketing, Product Management is accused of not understanding the customer.

If customers report bugs, Product Management is asked to immediately identify fixes.

Product Management becomes everyone’s favorite punching bag. It’s amazing how fast this happens.

The bottleneck syndrome: Somewhat related to the scapegoat syndrome, except this one is often self-inflicted.

The new Product Manager declares, “Product Management owns the product.” And sure enough, soon he or she does indeed own everything to do with the product.

All decisions, all issues, are swiftly sent to the Product Manager, who quickly gets swamped with putting out one fire after the next.

Pretty soon, no department is getting the support it expects, the backlog piles up, delivery timeframes get jeopardized, the execs are still waiting on the product strategy, and everyone is pointing to Product Management as the bottleneck.

It’s a sucky place to be.

Eyes Wide Open

So before you introduce Product Management into your organization, or sign up as the first product management employee, be mindful of these traps.

Have you ever been one of the first product management employees hired into an organization? Please share your story!

This post was also published on OnProductManagement.net and is part of a two-part series. Read part 2 here.