29
Nov 17

Get People Talking! How To Use Open-Ended Questions For Market Discovery

In my last post I talked about the importance of “talking to customers.” In that post I focused especially on what you do with the market discovery knowledge you get from customers once you found it. (The “product management system of record,” I called it.)

In this post I’ll be more to the point: How do you actually have these conversations? How do you structure the conversation so you get the information you need to know, and so the customer feels it’s worth their time?

Even if you aren’t (yet) an expert in your product, talking to customers one of the best ways to create value. It’s a great way to learn quickly about the relationship that customers have with your product if you are a new product manager, or new to the company.

No matter your experience level, the fundamental benefit is that customer conversations help you discover new problems your product could solve.

(Accompanying this post, I’ve created a “cheat sheet” with a list of good questions for customer conversations, and some techniques for using them. Click here to download the cheat sheet.)

Problem space

Up to a point, the more you know about the product and the space before these conversations, the better.

But even if you know the domain and the product well, it’s good to go into these conversations with a “beginner’s mind.” This helps you keep the conversation in “problem space,” not “solution space.” As experts and as technologists we love solution space – it’s where we get to do cool technical things. Even our customers like solution space.

In market discovery activities like talking with customers, we strive to stay in problem space – because as you know, our biggest and most important job as product managers is to discover and validate new problems we can solve.

Let’s say you have the opportunity to talk to a customer when you’re brand new to the company and you don’t know much at all about the product, the space, the domain, the customer problems. How would you initiate that conversation? How would you handle the inevitable questions about the product that you’ll get from a customer?

I’ll answer all these questions in the rest of this post.

A simple formula for customer conversations

The formula is simple. Introduce yourself, and set some expectations.

“I’m Nils, I’m a new product manager here at Acme. I’m excited to work with you and our other customers to help you create value. I’d love to ask you a few questions about how our product is working for you, and about your work in general.”

After that introduction, I start with something along the lines of

“Can you tell me what you do?”

People love to talk about themselves. Not only will you learn a lot, but they’ll actually like you more.

Two powerful phrases that will always help you in any customer conversation are:

  • “Tell me more.”
  • “And then what?”

The customer will probably start by giving a brief description of what they do. You have an immediate opportunity to ask, “Tell me more.”

At this point the customer knows you are interested enough to listen to their story. You can help them continue their story with “Tell me more” and “And then what?” Or you can take the conversation down other roads. For example, how they use your product.

Learning about your product

At some point, you might want to throw in something like,

“How does <our product> help you with that?”

Other good and interesting questions you can use, without knowing much about the product at all, are:

  • “What are some day-to-day things you do with <our product?>.”
  • “What are some things you do only periodically with <our product>, like at the end of a project, or at the end of a quarter?”

So that’s a first set of questions that will reveal a lot. I wouldn’t recommend going through this list of questions as though it were a questionnaire. At any moment the conversation can take an interesting turn, or you can take it deeper with “Tell me more about that.” Or “And then what happens?”

How to handle a product question

OK, here’s the big challenge – what if the customer asks you a question about the product you don’t know the answer to?

You know what? This is always a risk! Even after years of experience with a product, there will be areas where you are not the expert, even if as the product manager you are the most knowledgeable person on the team. So you’d handle this situation more or less the same way no matter your experience:

“Gee, that’s a great question. I don’t know the answer off the top of my head, but I know who to ask and I’ll get back to you immediately with some more detail. Can you tell me more about why you’re asking?”

Notice two things. First, I added an open-ended question to my response. The customer asked a technical question, but it probably arises from some problem the customer is experiencing. I want to know more about this problem, how serious it is, how urgent it is to solve, and so forth. Second, I made a commitment to get back to the customer immediately with an answer. If you show good faith and responsiveness by providing the customer with an answer right away, you’ll go even further to build your relationship with this person.

Well, there’s a third thing to notice: I didn’t say “I’m a newbie and I know nothing.” I can say that if I want to, if it will help my relationship with the customer, but I don’t have to admit how little I know.

Bonus

Accompanying this post, I’ve created a “cheat sheet” with a list of good questions for customer conversations, and some techniques for using them. Click here to download the cheat sheet.

A sample conversation

Here’s a conversation (hypothetical) I might have with a customer. (The domain is project management.)

“Hi, I’m Nils, I’m a new product manager. Who are you and what do you do?”

“I’m Bob. My official title is Senior Project Manager, but I like to think of it as Senior Goat Rodeo Manager, ‘cause that’s what it’s often like around here!”

“Bob, great to meet you, I can’t wait to learn a lot more about goat rodeos and how you use our product to help you with those. Can you tell me a little more about the goat rodeos you manage?”

“OK, LOL – internally we don’t call them that, of course (even though that’s what they sometimes are). I work especially on IT projects, and on projects where IT is working with other departments. Things like putting in a new phone switch and phones, or rolling out the ERP system.”

“Oh, a new ERP system. That sounds like a big project. Can you tell me more about how that project worked?”

(Customer talks about it. You notice they don’t mention your product.)

Asking about our product

“Bob, did you use our product for that project?”

“No, darn it! We didn’t have your product when we started that project, and we did the whole thing with our old method. It was a mess.”

“How do you think it would have gone differently if you’d had our product?”

(Bob talks about the benefits of your product – this is gold, by the way.)

“Have you run another project since that’s comparable to the ERP project, but using our product?”

“Oh yes. And it’s so much better than what we had before. I mean, it’s like the goats are a little bit tamer now, if you know what I mean.”

“Can you tell me more about that?”

(Bob talks about some of the reasons he likes your product, and, most likely, some of the things he’d like it to do better.)

“Bob, you mentioned X (a big benefit he gets from your product). Can you tell me how having X has impacted your work?”

(Bob answers – this is going to be gold as well. He’s going to talk about how his work is more efficient, or how his work is better received, or higher quality, or whatever.)

“Bob, what would happen if you couldn’t do X with our product anymore?”

(The goal of this question, and you might want to be careful about asking it, is to get an emotional reaction to the feature and what it enables him to do.)

Customer conversations have overlapping benefits

This is one way this conversation could go, out of millions. It represents about ten minutes, at most, of an interaction. In the process of this conversation I’ve learned a lot:

  • The types of projects that at least one customer considers appropriate for my product.
  • Some specific words that my customers use about their work, and about my product and its benefits.
  • One more specific benefits they got by using my product over what they were using previously.
  • Perhaps some level of understanding of the emotional connection Bob has to my product and to the results that he’s getting with my product.
  • Ideas for improvements, based on the things that Bob feels the product could do better.

Bob described the benefits he’s getting from the product, in his own words (which can often be directly used in marketing and sales engagements).

I got insights into how the product could be improved from his perspective. And I started to create a relationship with Bob that will benefit both him and me into the future.

It will benefit him because he now knows that I’m interested in what he does, I understand better what he does, and I will probably take his interests into consideration when I prioritize features.

And it benefits me because I now have a customer who knows I’m interested in him and his opinions. I can go back to Bob in the future to get more of his ideas, and to validate my ideas and designs and new features with him.

You can guide the Market Discovery conversation

I structured this conversation as a combination of open-ended questions, requests for more information, and a few close-ended questions (“Did you use our product for the ERP project?”) to help determine if I could go down a certain path.

I started with the list of questions from above, but then, as I learned more from Bob, I was able to move into new areas (especially using “tell me more about that” variations). As a result, I have a great relationship with Bob the Goat Rodeo Manager, and I know about how at least some of our customers perceive the product.

Finding product gaps

There are a lot of other directions I could have taken the conversation. For example, if I were interested in finding new product opportunities, I might use a line of questions like one of the following:

“What do you miss about your old tool now that you are using our product?”

This could help me learn about product gaps and areas where current customers might be actively frustrated.

“Before you got our product you were mostly using spreadsheets for managing things like your ERP project. What are you still using spreadsheets for?”

(If Bob is still using spreadsheets for project management tasks, those would potentially be ripe opportunities for new product features. Or perhaps for me giving him guidance on how he could use our product for those parts of the process as well – maybe he just doesn’t know how to do it, or needs some training.)

Three things for you to do right now

  1. Create a set of questions for doing customer interviews about the topics you need to learn about, and practice them so you’re natural when talking to customers.
  2. Schedule interviews with your customers, even if you don’t know very much about the product yet!
  3. Practice using these questioning techniques not just on customers, but on co-workers in other departments, and even in your regular life. They are very powerful!

Closing notes

  • Two recent episodes of the All The Responsibility, None of The Authority podcast are also about asking questions and doing market discovery, so you might want to check them out.
  • Don’t forget to download the bonus list of questions that goes along with this post (and with the podcast episode).

Tell me in the comments about your memorable customer conversations. I’d love to hear about any funny or meaningful interactions you’ve had, and the insights you gained.

 


21
Oct 17

Visiting Customers? What?

Nothing Important Happens In The Office

We product managers are always told that we need to spend a lot of time with customers, and with the market, to create successful products. This advice, while good, is not actionable. It’s vague and aspirational. And, indeed, you might even ask “why is this good advice?”

It's very difficult to find the signal - market problems - in the noise - our conversations with customers and prospects.

It’s challenging to find the signal – market problems – in the noise – our conversations with customers and prospects.

In fact, there are a lot of questions:

  • What should you be doing with those customers when you visit them?
  • Why is this so good?
  • How do you do it?
  • How do you track that you’ve done it?
  • What do you do with what you’ve learned (if anything)?
  • How does spending time with customers and the market make you and the company more successful?

Without guidance on these questions it can be a paralyzing situation. And believe me, many product management organizations are paralyzed in this area. With the result that they tend not to spend much time doing it.

That’s a big problem. If you remember the Secret Product Management Framework, the fundamental thing we work with as product managers is market problems. And finding those market problems depends on what customers’ real issues are, the ones they will pay to solve.

Finding a previously unsolved, important customer problem can make you, and your company, a lot of money.

And you can’t just guess – that’s a sure road to failure. So you have to get out there.

Strategy/Methodology

Even if you are “going out there” are you doing it as effectively as you could be? To be successful, you need a strategy. And you need a methodology for making use of what you learn.

You need to talk to your customers, your prospects, your competitors’ customers, and even people who aren’t buying anything, but are like the people in your target market. What you’re going to do is ask them open-ended questions about what they do in their jobs, and about their frustrations, problems and challenges. (I say “jobs” but it could just be “life” as well!)

I have covered many techniques for how to do this in earlier blog posts, including links to other peoples’ articles.

But simply gathering all this information is not enough. The signal you get from the market is weak. It’s often via offhand remarks, or even observations that you make. These lead to further investigations and lines of questions. Then, with luck and more conversations, you may find you’ve discovered a real market problem you can solve.

Building a weak signal detector

We have to have a lot of these conversations to get enough signal, and even then, the signal has to get through our crowded brains to emerge. We PMs are cognitively overloaded – we all know that – so expecting weak signals to get through is a pretty high expectation.

So you can use use tools to enhance your cognition. (And I don’t mean Adderal!) Many of our knowledge-oriented tools are focused on improving the weaknesses of our cognition, like remembering things (all the to-do lists and GTD applications and wikis). Or organizing things (photo organizers, folders in your OS, tagging in Evernote, dropbox). Or helping to find patterns in a lot of data (big data, Excel charts, even search).

Well, you have all this data – all your conversations with customers – but you don’t have tools to help you winnow that data. You don’t have tools that are good at helping you find the “signal” in the noise of many customer conversations.

You May Have To Roll Your Own System of Record for Market Problems

That leaves you the option to “make your own.” By which I mean, figure out how to use the tools you do have at your disposal to enhance your cognition. This might be a spreadsheet, or a wiki page, or an Evernote notebook. Or a combination of any of these and many more options.

Because it’s not a purpose-built tool, it’s likely to require more manual work than you want. But, the return can be very high.

By the way, this is one reason methodologies like Strategyn’s ODI (also known as “Jobs To Be Done”) are so compelling. They actually give you a set of interview questions, and a form into which to put the answers. And they, amazingly but maybe not so amazingly, help people come up with new product ideas that succeed.

How Do You Do It? Find Out Next Time

I’ll continue this topic in the next article. In the meantime, you can check out my podcast episode on a “roll your own system of record” for some ideas. I have a few other posts you can check out as well.

I’d love to hear what you’re doing now to capture and analyze your customer conversations.

 


01
Oct 17

Should You Be A Product Manager?

Have you built something? Have you led a team?

Have you built something? Have you led a team?

Product management is a hot, hot profession right now. It’s one of the most important roles in a product company, especially in high tech. But is it right for you?

If you’re wondering about this, or want to scope yourself against a basic set of guidelines for product managers, this post is for you.

What I’m looking for in a new product manager

There are definitely some skills you should have – technical, communication, decision-making. And you should have a flexible mind, love uncertainty, crave a fast pace, and enjoy working with people.

But what I look for most is that you’ve made something, that you worked with people to do it, and that it solved someone’s problem.

What have you done?

One way to check if you’re ready: reflect on what you’ve already done in your career, or in school, or perhaps as a volunteer or in a high school job.

  • Have you built things, or worked with others to build things, that addressed someone else’s problem?
  • Have you led these teams in some way (ideally without authority, just by influence)?

For example, I worked with a graduating college student once whose resume said this about his senior project:

  • Redesigned shipping packaging for Hardy Diagnostics for their petri dishes.
  • Shipping testing for new designed packing products.
  • Assembled, built, and utilized machines for packaging design and shipment testing.

We spent some time talking about what he did, and it turned out he was underselling a bit.

He’d led a team. He had to validate the problem he was asked to solve was significant and worth solving. He had to test that the solution he and his team designed and implemented actually solved the problem effectively. And he had to ensure that his design could be manufactured on the customer’s existing machines.

The point is that he had done a limited version of product management in this project. He’d led a team, to create a solution, for someone else, that had market value. It didn’t show up that way on his original resume, but it was there.

I felt comfortable recommending product management to him as a potential career path.

We Like People Who Build Things

When I’m talking to someone who wants to get into product management – like when I coach young people on their resumes during their job search – I always explore these stories. How they built something, or worked with others to build something. How they made sure the thing they were building was worth building. How they got people to work with them. How they took the solution to market, perhaps. And how they validated the solution worked – that it solved the problem.

If a person doesn’t have some stories like this, I am suspicious they want to get into product management for the wrong reasons.

I Make Things, That’s My Job

And after you’ve been a product manager for a while we assume you have proven to yourself and others that you should be a product manager, that it’s the appropriate job for you. And at that point I start asking a whole different set of questions, of course!


01
Sep 17

How To Say “No” To A Feature Request

No (picture credit at the bottom)

Sometimes No Is The Right Answer

Can you talk to me about a time when you had to say no to a customer? Why did you have to say no? How did you handle it?

Customers often make feature requests that seem obvious on the surface, but which in fact are misguided or a bad idea. My goal is to be able to tell them that we won’t implement that feature, and have them thank me for that answer. I do that by leading them to make the decision themselves. This is a matter of asking the right questions in the right way.

Oh, That’s A Terrible Idea!

For example, let’s say your product is a project management tool. And one of your big features is being able to staff a project by role. For example, you can specify that the project will take two DBAs, three Developers, a Project Manager, and a Business Analyst. And you can say how long you need each of these, and even define when on the calendar they are needed.

That’s a very powerful capability. But one of the first things you think of when you look at it is, “Wouldn’t it be cool if I could use skills in addition to roles?” For example, some Developers know Java, and some know .Net. Our customers often asked for the ability to use skills, not just roles, to help them staff projects.

This feature request turns out to be a bad idea, and very difficult to implement in a usable way. So I used the following approach when I’d get that request.

Leading The Customer Along A Path

First, I’d acknowledge that this seems like a good idea, and that other customers have asked for this capability.

Then I say “I want to understand more about what you’re looking for.” It’s always a good idea to ask the customer this question, and the follow-on questions, whether or not the request is valuable.

The resulting conversation can head in several directions. One is that we actually can do what they need (which is often not what they ask for). This happens all the time: customers ask for features that already exist, or they are trying to solve a problem that’s already solved a different way.

You Can’t Handle The Truth

However, if they truly are looking for something new, as in this case, the next step is to drill down into how they expect that might work. For example, I always ask about how they expect to manage the association between skills and resources. Who maintains this information? How do you keep that relationship trustworthy? How will it be vetted? Does it capture enough information that it will be useful in allocating resources, etc.?

Usually by this point in the conversation the customer starts to hem and haw. It turns out that they don’t have a way to ensure the information is accurate over time. And as a result they also start to understand how supporting skills could actually be counterproductive if the data isn’t kept accurate.

Closing The Conversation

I’ll usually say at this point that we have considered this enhancement, but we also haven’t come up with a solution to make usable in real life. And that other customers agree as well that the cost of maintaining any model that was used for resourcing based on skills would likely break immediately. (In fact, for many of our customers just maintaining the role mapping for resources can be difficult to maintain.)

By the end of the conversation the customer typically admits that they don’t have a good use case for making this work. And we move on. Of course, I’m always gracious throughout this whole process. I’ll associate the customer with the enhancement request. And I’ll say that if we crack this nut, if we figure out how to make it work and make it valuable, it’s a common request and we’ll prioritize it along with all our other work.

What’s amazing is that the customer usually feels better about the product, and about me, at the end of this process. I just saved them a lot of headache (if we’d actually done their feature). And I made sure that my resources could continue to be focused on more valuable capabilities that they’d benefit from.

Leading The Customer To Say “No” Themselves

The steps are:

  1. Find out what the customer is really asking for – what’s the desired outcome behind the feature request?
  2. If you already solve it, then fantastic – you don’t have to say “No.”
  3. Otherwise, help the customer understand the implications of the enhancement – in the case of using skills for staffing, the implication is a huge overhead in maintaining data integrity, for which there is no good solution.
  4. Lead the customer to say “No” themselves.
  5. Make sure to capture the enhancement anyway, and promise to reconsider if a good solution presents itself.

What If It’s Not A Terrible Idea?

Of course, this is the case where it’s an enhancement request that you don’t want to do and that isn’t a good idea anyway. It’s a different process if the enhancement is a good idea, but you are just unable to prioritize it highly enough to replace something else on the roadmap. I’ll do another article on that soon.

(Image “No” copyright (c) 2014 Henry Burrows, Attribution-ShareAlike 2.0 Generic – CC BY-SA 2.0


18
Aug 17

A Better Approach To Demoing Can Turn Sales Around

A Sales Demo Challenge

At one of my previous companies our new logo sales – that is, new customers – were tanking. The account reps were not hitting quota on new logos.

The sales engineers felt this was due to a large degree to our “story” on agile. Our product was not as strong as some of our competitors for managing agile projects. Even though we had a lot of customers successfully using it for agile projects, the sales engineers felt severely challenged because we didn’t have the features to show in the sales demo.

Doing a great job of go-to-market is one of my passions. I love working with marketing and sales to make sure they can sell my products effectively. But as I wrote the recent post on how my various articles align with the Secret Product Management Framework I realized I didn’t have many articles on go-to-market. So I thought I’d share a few go-to-market related stories. The first one is about “how to demo.”

Problem One: It’s Not About Agile

Because I have a long, strong background in agile, having created an agile tool myself (as a component of Accept360) and been involved in multiple agile transformations, the sales engineers asked for my help.

After reviewing the current sales demo, and following several long discussions about how to sell (from me to them), I gave them two specific areas to improve.

First, they were doing a feature-function type of demo. It was full of “Our product does X” and “Let me show you how our product does Y.” All without reference to whether the customer cared about X or Y. That wasn’t doing them, or our customers/prospects, any good.

Focus on customer’s problems

I had them rework the demo to be focused on the customer’s problems and how our product solved them. We had to learn about the problems in earlier discovery calls, or simply by asking questions during the demo.

Making the demo about the customers themselves is a very powerful technique. Talking about the problems that concern them shows we care about them.

Problem Two: Use all your ammo

To get out of the “agile project management” minefield, I had them move the agile discussion up a level. Our product’s portfolio management capabilities were a significant differentiator. But they weren’t being used effectively to differentiate in the demo.

Portfolio management has always been an “agile” activity. You take all the projects you want to do, and figure out which is the most important, and do those. You can think of it as “stack ranking” your project portfolio. Our solution was better than the competitors in this area, and we could reset the conversation.

Back on Track

These changes made it easier to sell, and easier to beat competitors. As a result we reversed the trends on new logo sales, where the demos are most important. I asked the Sales Engineering VP for her assessment, and she said “We really changed the way we demo. And we beat our quota on new logos the last three quarters in a row.”

Tying it All Together

The key takeaway in this story, and the relationship to the Secret Product Management Framework is this: if your product doesn’t actually solve a market problem, your demo doesn’t matter much. No one is going to buy it no matter how you take it to market.

On the other hand, if you solve a problem, as this product did, then your go-to-market can have a significant effect on how successfully you can sell the solution.

For more on demoing check out the article Everything I Wish I’d Known Before I Started Demoing SaaS from Joanna Weibe of Copyhackers. She goes into a lot more detail about these and other techniques for making your demo a LOT better.


11
Aug 17

How Are You Going to Fix Onboarding?

You have a team of engineers and a three month runway – how are you going to fix onboarding?

That’s a question I actually got in a product management job interview a while ago. My answer was, “that’s a really good question but I have no way of answering yet.”

Is this an operating room problem or an aspirin problem

Operating room or aspirin?

This is the same question as “Here’s a team of surgeons, and I’ve booked an operating room. We have a patient with a pain in his foot. What operation are you going to do?”

I would hope it’s obvious that no doctor would ever do an operation – of any kind – without knowing more about this “pain in his foot.” Maybe the patient needs an operation, but maybe the patient needs an aspirin.

Onboarding Is Not A Customer Problem, It’s Our Problem

When customers aren’t behaving the way we want them to – for example, if they are not onboarding fast enough or in big enough numbers – we need to treat that as a “signal,” not as the problem itself. It might be a problem for us but it’s not a problem for our customers. Our customers are having some other problem, and that’s causing them not to onboard.

Without doing some research, we have no idea whether this is an aspirin problem, or an operating room problem.

And the cost of doing the wrong thing, even if well-intentioned, can be huge.

If I had a team ready to go, and an onboarding challenge, I’d go find something else for the team to work on. Then I’d go do some research on onboarding. Why aren’t customers successfully using our product? There are many questions I’d need to explore.

  • Are there any segments of our target market who are onboarding quickly?
  • Why are they successful?
  • Are there segments that are particularly slow to onboard?
  • Do we know why those people are trying out our product in the first place? What use case are they trying to address?
  • Is our product good for that use case? Have some customers had success in that area?
  • If we know some customers are successful, why aren’t the others?
  • Can we do something to help those customers achieve their goals more easily?
  • Is there something confusing about the onboarding process?

Start With Simple Interventions

Once I start getting answers, I can start doing interventions. Depending on what I learned, I might be able to start with easy, low-cost mitigations, like sending a drip email campaign after people sign up, giving them examples of how to accomplish their use case. I might update the landing page, from where they download my product, to ask about the use case they want to address. I might send some use case-specific templates to customers, based on their answers. Or success stories from people who used our product to solve that use case.

These tests would only take a few weeks to give us meaningful enough results (assuming we have a lot of signups) that we could then think about how to apply engineering resources.

The Same Tools As Growth Hacking

This looks a lot like “growth hacking” – “a process of rapid experimentation across marketing channels and product development to identify the most effective, efficient ways to grow a business” – and it’s based on the same set of tools.

As product managers, we need to find market problems, create solutions, and take the solutions to market. (This is the basics of the “Secret Product Management Framework.”) An onboarding problem often means we haven’t created the right solution (yet). So we have to do more work, via testing and understanding our users, to define a better solution.

What would you do with a team of developers and a three month runway?


04
Aug 17

This Framework Gives You Product Management Super Powers

Breakthrough! The Secret Product Management Framework

Finally writing down the Secret Product Management Framework was a revelation for me. It put all the activities I do as a product manager into perspective.

We find and validate market problems for which customers will pay for a solution. We then guide the creation of solutions to the problems. And then we take the solutions to market.

One test of a new framework is how well it explains “previous observations.” In this case, the previous observations are the articles I’ve been posting on the blog. In this article, I tie the older posts to the framework.

Finding market problems

Over the years I’ve written quite a bit about finding and validating market problems. From rules of thumb about the characteristics of good market problems to solve, to a series on how to be “badass” at finding market problems:

Creating and guiding the creation of solutions

Of course, a huge amount of our time and energy is taken up in the “solution” area – writing requirements, prioritizing, agile development, roadmaps, working with developers, and ensuring quality.

Taking the solutions to market

Taking your product to market means finding the people who have the problem you solve, making sure they know you have a solution, and convincing them that your solution is a better option for them than any other way they can spend their money.

The other layers

The core product management activities are finding market problems, creating solutions to the problems, and taking the solutions to market. But those all happen in the context of the organization’s strategy, the skills of the team, the tools the team gets to use (or has to use), and the management of the product management function.

The full framework – core and supporting components.

 

Skills

Product management requires skills like writing, technical knowledge, and problem solving.

Infrastructure

Of course, the tools we use are critically important. Unfortunately, most of us don’t have that many good choices.

Management and Strategy

I haven’t written much about the management of product management teams, or about strategy (although I mention it in a few posts, including those on prioritization, where it has the most impact on product managers). I’ll put some focus on these areas going forward.

Call To Action

Let me know if you find this categorization useful. And of course, if there’s a topic you want to learn about that I haven’t covered, please let me know.


04
Aug 17

A New Focus On Product Management Opportunity

Looking through to the next stage.

A long work in progress

This blog has been going for a long long time. It started as a site to share ideas and lessons I’ve learned in my career as a product manager for enterprise software products. Recently a bigger theme has started to emerge and coalesce. It’s more ambitious than my initial (lack of) vision. And it resulted in the Secret Product Management Framework, a better way to understand product management

And it raised a question: could I make the blog more valuable to you? Could I make the lessons and guidance more concrete and more actionable? Could I give you a roadmap for taking these ideas and applying them to your own product management career to create new opportunities? To speed up your effectiveness and your success? And the answer is, yes, I can do that. And how do I do it? By following my own advice in the “structure is good” post, and putting some more structure around the blog.

The future is now

It starts with the next post, which puts a selection of my previous articles into an organizational structure that makes it easy to see how they all tie together. I’ll follow this with more blog posts that fill in the blanks and give even more actionable techniques. I want this blog to help you move faster up the curve of product management effectiveness.

Are you the target audience? Yes.

Who is this blog for, and in particular, who is the “new” target for this blog? In reality, it hasn’t changed, but I’m going to make it explicit. This will help all of us. It certainly will help me with creating content.

The primary focus is new product managers. I want you to understand the secret handshakes and arcane product management knowledge. You’ll learn the answers to key questions: Are you suited to product management? What skills do you need? Do you have the right mindset? How do the jobs you’ve done in the past map to product management? How do you get the skills you need to become a good product manager based on where you are? 

On the other hand, if you’re an experienced product manager, you’re probably like me. You constantly want to learn new techniques, mental models, and approaches. If you are always on the lookout for new ideas and new information that will help you level up, you will continue find value here.

What are three actions you can take today to make use of this information? Ha ha – just kidding. That’ll come later!

Guiding mental models

Much the content on the blog naturally ties into the Secret Product Management Framework (SPMF). You can think of the SPMF as the North Star or guiding mental model – it’s a fundamental structure for thinking about product management. You’ll see this clearly in the next post, where I’ll show how the existing content ties into the context of the SPMF. This should make it easier to use the existing content more effectively.

I will also use the V.A.L.U.A.B.L.E. feature spec rubric as a key mental model and organizing principle. The V.A.L.U.A.B.L.E. model and the SPMF work together and synergize powerfully. It’s worthwhile making those ties explicit.  

Call To Action

Let me know what you think of this new direction! Please tell me the topics you want to make sure I cover in the next year. (And don’t forget to sign up for the mailing list to get some good stuff.)


16
Jun 17

To 10x Your Profits Start With Retrospectives

20% is boring

As many of you know, there’s a technique called a “retrospective” in scrum, or you might call it a debrief. After each sprint the team spends a short amount of time reviewing what went well, what could be improved, and what they should stop doing. The goal is for the team to learn quickly from each sprint.

So, let’s say I really wanted my team to start doing retrospectives, and the team is unwilling. So I share this little bit of research with them:

In a meta-analysis of 46 studies on debriefs (also called after action reviews or lessons learned), Scott Tannenbaum and Christopher Cerasoli found that when appropriately conducted, debriefs can lead to a 20-25% average improvement in performance.  The authors found performance improvements in the use of debriefs with both teams and individuals.  (Thanks to the Center For Evidence Based Management for sharing this study.)

Obviously, based on this data retrospectives and debriefs should be a no-brainer. They are easy and they make your team 20% more effective. But this data still doesn’t motivate most teams to act. Why not?

Because a 20% improvement isn’t enough to get the team to change its behavior.

I need a 10x benefit

This is a general problem for product managers. 20% improvements aren’t interesting to people, whether they’re your customers or your team members. One of my product management rules of thumb is the “Factor of 10 rule” – people aren’t willing to make a change – to a new product, to a new process – unless they get a 10x benefit on a metric they care about.

Back to my problem. I still think retrospectives are a good idea, because I want my team to learn faster. What if I can figure out how to pitch retrospectives as making an order of magnitude difference to something important?

When does 20% equal 10x?

Somehow, I have to make 20% appear to be 1000%.

And that’s what this post is about. (It’s not really about retrospectives.)

Let me tell you one of my favorite stories. At NetIQ we improved the uptime of Windows servers by 20%. That’s nice, but as I said above, it’s not compelling.

But by improving uptime, we also reduced downtime. If you do the math, we reduced it by a factor of nearly 100 – two orders of magnitude! And I can assure you that our customers cared a lot about having less downtime. That’s a story you can tell, and indeed at NetIQ we told that story well.

Can we apply the same kind of thinking to “20% performance improvement?” Somehow turn it into an order of magnitude improvement?

Well, here’s one way. It’s similar to the “downtime/uptime” calculation we did at NetIQ.

Teams improve by learning faster

How fast will the team learn if they don’t do retrospectives? I assume the team’s performance will increase over time naturally, but kind of slowly. Let’s call it 2%. So, if retrospectives increase that rate to 20% … I get a factor of 10x right there.

With this data I can say, “I recommend the team start doing retrospectives – your performance will improve 10x faster.” Retrospectives accelerate the team’s learning, and they accelerate it by a factor of 10. That’s a much better pitch. And learning faster is a benefit that most teams consider important.

How does 10x faster learning affect the bottom line?

But now let’s make the problem a little harder. I don’t just want the team to do retrospectives, which are free. I want the company to buy the team a tool to support retrospectives. And unfortunately, the execs don’t care that much about team learning, no matter what they say about “the company’s people are our most important asset!”

So I have to go to the next step. I need to show a dollars-and-cents business benefit of “improving performance 10x faster.”

What happens when you accelerate your learning by a factor of 10? Well, the whole point of having a higher performing team is to release higher quality products faster.

And what happens when you introduce higher quality products to market faster? You get more revenue faster.

What happens when you get more revenue faster, but with the same team and the same level of effort? All the additional revenue goes straight to the bottom line. So your profit grows, and it grows faster than it would have.

Triple profit for almost no cost

Let’s put some numbers around that. Let’s say that improving the team’s performance results in a 10% improvement in time to market, which results in a 10% improvement in being able to close sales. In any period I get 10% more sales than I would have.

Let’s also assume that our profit margin was 5% before. If I had $10 million in revenue in a quarter, our quarterly profit was $500,000.

With my improved team performance, all the costs are the same, except I’m spending a little bit more on a tool – say that’s $3,000 per quarter. Otherwise, all I’m doing differently is having another short meeting every few weeks. I didn’t add anyone to the team. But now my revenue is $11 million in the quarter because I got better product to market faster. My profit is now $1,497,000.

Improving the team’s performance by 20% resulted in tripled profits!

Oh wait – did I say “triple?” How about 10x my profits?

This is even more impressive if the company is barely profitable. If our profit margin is only 1% before improving the team, then improving the team can increase my profits by a factor of 10.

Unwinding the example

If I want to pitch retrospectives. I’m going to use some of these ideas. If we do retrospectives or debriefs:

  • The team will learn 10x faster
  • Therefore, we will get better quality products to market faster
  • The result will be as much as 10x the profits

I illustrated this in terms of retrospectives. But the same kind of thinking can apply to many other kinds of improvement.

How to turn 20% into 1000%

  1. Find the baseline, call it X. In the example the baseline is the rate at which the team is improving without doing retrospectives. They’ll naturally improve some, but not as much. Let’s say it’s 2% (per year).
  2. Find the improvement to the baseline, call it Y. For retrospectives, it’s 20% per year.
  3. What’s the ratio between the improvement and the baseline (X/Y)? For retrospectives it’s 10. This means that in the retrospective case, the team is getting better 10x faster.
  4. Optional next step: What does that 10x improvement mean in terms of business results? There are a few big ways to improve the business – get to market faster, win more of the deals you get into, get into more deals, open a new segment, increase the total addressable market (TAM) of the segment you’re in. Improving the effectiveness of the development team can impact four of those five.
  5. Figure out how impacting one of more of those factors affects revenues and profits. Especially for profits, and especially if you are starting at a point of low profits, you can often get amazing multipliers for just improving your processes a little bit.

 


02
Jun 17

How To Talk To Your Executives About Agile

People have asked me “How can I get my execs to support an agile transformation? They don’t like that they can’t predict anything.”

Reframe the Agile conversation around value

Graffiti on a wall spelling out the word "Value"

Orient the conversation around value, not around methodologies. (Picture credit below)

This is never going to be an easy conversation, but I recommend reframing it from the outset. Don’t talk about scrum or methodologies or the Agile Manifesto. Instead, talk about delivering value to the market and how your products and your company can be more successful.

Among the things keeping executives up at night are the following three questions:

  1. How can I get higher quality products to market faster?
  2. How can I motivate my teams and help them improve?
  3. How can I stop failing in my predictions of what we’re going to deliver?

Help your executives sleep better

If you take these questions to heart, you’ll find there are solutions. And as you implement these solutions, you end up doing agile or something that looks very much like it. (Another way to say this is that you implement agile to get good answers to those questions.)

  • To get higher quality products to market faster, you need to focus on and prioritize adding the highest value capabilities to the products. And you must stop adding low value capabilities. You get two benefits from this. First, because you aren’t working on lower value stuff, the time the team spends is intrinsically higher value. And second, your team is naturally going to be more motivated because they are working on higher value stuff. Focusing on value helps with the first question and part of the second question.
  • I’ve already talked about how to motivate your team more effectively. How do you help them get better? How do you accelerate your team’s learning cycle? You make the cycle of review and learning a lot faster. The “retrospective” is a key part of the scrum methodology for just this reason. The team does its learning as closely as possible to the action. It also helps if you can have the team accomplish things on that short cycle as well. You may need to do clever partitioning of those important things you are working on.
  • There’s only one way to stop failing in your predictions. You must stop trying to predict the future. We all know it doesn’t work. Even if you have a concrete plan, with “good” estimates, you will not hit it. (It’s never been done.) Instead of predicting what you will deliver when, use a value-based approach to talk about what’s coming. You can confidently say “Every release will have the most valuable capabilities we could deliver in the time frame.” You may not know exactly which capabilities those will be in advance. But you can be confident they are the most valuable things you could possibly deliver. So rather than focusing on hitting a schedule – which is an internal target that customers mostly don’t care about at all – you are focusing on delivering value to customers – which customers do care about, which is much more valuable.

Value and velocity – related but not the same

I’ve separated maximizing the value of the results the team delivers from continuously improving the team’s ability to deliver.

These two ideas are often munged together in agile discussions. Indeed, by focusing your team on delivering value fast, the team naturally gets more motivated and faster.
But the second half, of accelerating the learning of the team, is not necessarily about “agile.” The practice of retrospectives or debriefs gives you the other dimension of team improvement – continuous learning. To accelerate continuous learning, you need to make the pace of the retrospectives faster. It’s much better to do learning near the actual experience. And since agile methodologies have short sprints, doing a retrospective for each sprint is a natural way to accelerate learning.

From Value-focused to Agile

If you combine all these thoughts, there are four aspects that combine to make more productive teams:

  • Making sure you’re always working on the most important thing or things
  • Continuous learning
  • Not predicting the future
  • Fast paced iterations

And, if you have those four things, you get four side effects, all very valuable:

  • Agile as a side effect
  • More effective teams as a side effect
  • More revenue faster as a side effect
  • Higher value products to market faster as a side effect

And there’s one other side effect. If you are working in order of importance, you can also push that practice back to the requirements and planning stages. The product managers only need to write requirements and do planning on the next most important capabilities. Requirements for less important capabilities can be delayed until they are needed. This means the development process can start sooner. And that accelerates your time to market even more.

How you can put this into practice today

Here are three things you can do today to start putting these ideas into practice.

  1. Start thinking about value value value, all the time. Only work on the most valuable things you can. Or, to put that another way, don’t work on things that aren’t valuable, even if they are cool or fun.
  2. Make sure your development team understands the value of what they’re working on. You can use the template I mention in this article to help: This New Template Helps You Write Better Product Requirements.
  3. When you talk to your execs about agile, don’t talk about agile, but about delivering value to market faster. Which results in higher revenue and more profits. Execs are typically much more interested in higher revenues and profits than they are in development and project management methodologies.

Image credit

  • “Value” by J.Lightning. Copyright (c) 2011 J. Lightning, Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)