Category Archives for "Product Management"

Storytelling For Product Managers – The TL;DR Version

In my last article, I covered a powerful storytelling technique in great detail. This article is the summary (the TL;DR) version.

Do you hem and haw when asked talk about one of your accomplishments? Do you stick to a “just the facts, ma’am” approach when telling a story? Are your stories falling flat and failing to have the effect you hoped?

The Most Basic – and Effective – Story Structure

If you are struggling with any of these challenges, and want to learn to tell great stories, I have a quick and easy technique for you. It’s not going to win you a Nobel Prize in Literature, but you should find it useful if you’re struggling.

I used to struggle with my stories, too. Telling stories about myself – such as the ones you use in a job interview – were especially difficult. I was more comfortable telling stories about my customers, but I was never sure I was hitting the mark.

Here’s Something You Already Knew, But Didn’t Know How To Use

We know already that stories need a beginning, middle, and end. This is the most obvious thing in the world. But if you’re like I was, you don’t quite know what goes in each section.

Here’s what you do.

StructureExplanationExample
The beginning of the story is The Problem.Start your story with the challenge that someone - you, your customer, your market - was or is facing.“I didn't know how to tell a story. All my stories fell flat, and I didn't know how to make my stories engage my audience.”
The middle of the story is The Solution.This is what you did to solve the problem, or what your customer did with your product to achieve their goals.“I learned and started practicing a new way of telling stories that had specific formats for the beginning, middle, and end.”
The end of the story is The Results.The results are the benefits that arose from solving the problem. It should include the achievements and accolades that you received, or that your customer accomplished using your product.“Now when I tell stories people hang on my every word, and I have achieved the reputation of a raconteur and excellent storyteller.”

Two additional tips

  1. Business results – “sales went up,” “we got more customers,” “I turned around the revenue line” – are important, but typically not emotionally engaging. But they are useful to give the story gravitas.
  2. Make sure your story has emotionally engaging components both in the problem – “I was about to lose my job,” “it made me feel like an idiot” – and in the solution – “I got the reputation as an expert,” “my customer got a promotion.”

Problem-Solution-Results

This structure is called PSR – for “Problem-Solution-Results.” If you start using this structure for telling your stories about yourself, your customers, and your market, your reputation will soar.

To learn more about PSR, check my previous post.

What Are Your Storytelling Secrets?

I’d love to hear how you tell your stories. And if you have questions or thoughts, please drop a comment below!

1

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.

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

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.

 

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) 

2 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?

1 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.

3 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.)

2 People Don’t Buy Capabilities, They Buy Knowledge

A visual of a head with gears where the brain goes, and knowledge spilling out of it.

This guy might have too much knowledge.

Knowledge is power

Most of our tools and applications deliver capabilities, but users and buyers are always hoping that what they’re buying is knowledge. Knowledge of how to do the job. How to do the job faster, or with fewer errors, or with better outcomes. If we don’t put the knowledge in, the our users have to figure it all out themselves. They have to become experts in our tools when they really just want to be experts in their job.

Even if it’s basic knowledge that everyone knows, putting it in your product will make your product more valuable. And of course, the more knowledge you can embed, the better.

There are a ton of good examples:

  • Instagram (filters)
  • LinkedIn (“The most successful profiles have…”)
  • SAP (the Reference Model)
  • iPhone (visual voicemail)
  • Slack (Slackbot, do this then that)
  • IFTTT (example recipes, that are then augmented by shared customer recipes)
  • Any product that has a setup wizard or onboarding process
  • And it doesn’t have to be built in – can be an email-based onboarding process
  • NetIQ (Knowledge Scripts)

It’s not an accident that all of these examples are market-leading or paradigm changing. Compare what they delivered in their product versus what their competitors delivered. With rare exceptions, the competitors were offering the same capabilities but not in the form of defaults or a pre-made experience.

Examples

  • Instagram: If you’re delivering a photo app, it’s obvious to include the capabilities of editing and adjusting the images. And most photo apps have that capability. But Instagram one-upped its competitors by putting well-designed default filters front and center. Users no longer had to learn how to adjust a photo to increase the drama or appeal. An expert had already figured that out, and Instagram put that expert in your hand. (This is one of the ideas in my bonus content for this post.)
  • iPhone Visual Voicemail: I’ve said before that the iPhone’s Visual Voicemail feature is one of my favorite examples of killer product management. Today it seems kind of boring, until you are faced with a Cisco Internet phone on your desk, for example. All of us can do regular old voicemail (like the stupid Cisco system). We just hate it! Visual Voicemail takes all that stuff that we used to have to do manually and hides it all behind a “knowledge-full” experience. The iPhone was the first cell phone with this feature built in according to Wikipedia.

Low hanging fruit

The good news for all of us product managers is that the bar is extremely low in this area. Most of our competitors are not putting knowledge in their applications. Chances are you’re not either. So a little bit of embedded knowledge can create a lot of differentiation.

The other piece of good news is that defaults and knowledge provide differentiation in two ways. First, they provide the knowledge. But almost as importantly, they make the customer feel like you care about them, because you gave them knowledge. How many Instagram photos use a different filters than the default? It’s a very small percentage. But the idea that those other filters are there is extremely comforting.

Put this idea to use

Here are three things you can start doing today to put more knowledge into your application so you’re not just selling capabilities. (Or get the freebie for these and an additional bonus idea!)

  1. Find out how experts configure or interact with your product. Then create templates based on what the experts do. For example, if your product is a project management system, how do experts configure their projects? Create a project template based on their configuration. If your product is a collaboration tool, how do experts set up their groups and notifications? Give your users the option to have their system set up with groups and notifications based on that model.
  2. Look for situations in your application where most users take the same steps in the same order, most of the time. Make this set of steps the default, and make it achievable in a single action. You might want to leave the other options available, but if most people are doing the same thing most of the time, make it very, very easy to do that thing. (This is an example of the knowledge of the crowd, not of an expert, but it’s still knowledge.)
  3. You can also use your own insights into how the product should be used to get the most value. This is especially valuable if your customers are not currently getting as much value as they could. Sometimes this is because the steps to achieve the value are complex, easy to forget, or error-prone. Sometimes it’s because you expect the user to do some work outside the application to achieve the benefit. A great example is retrospectives. All us tool builders know that our customers will be more successful over time if they do retrospectives. And there’s actually very strong research data that says how much more successful they’ll be. However, no (or very few) project management/collaboration/development tools actually support retrospectives directly. Even if you can’t do it perfectly, if you put that capability into your product and our competitors don’t have it, at minimum you have a good differentiator. Ideally your customers will actually get the value of the capability (retrospectives in this example), and that will enable them to beat their competitors.

Over to you

I’d love to hear your stories of how you’re putting knowledge into your application. Please leave a comment or drop me an email.

And if you have other good examples of applications that include knowledge, I’d love to keep building my list.

This New Template Helps You Write Better Product Requirements

A watercolor illustration showing two profile heads with a jumble of "wires" connecting them.

“Communication” by Joan M. Mas. See below for image credit.

Effective Communication is Challenging

Product managers tell me – and the people managing product managers tell me – that one of their biggest challenges is communicating with the development team. People complain about:

  • Developers being poorly motivated, or having a bad attitude about what you want them to build
  • Getting the “wrong thing” from the developers – the feature they deliver is not what you had in mind
  • And other forms of miscommunication between PM and dev

Product management has all the responsibility, and none of the authority. If communication problems are happening, it’s at least partly product management’s fault. At a minimum, you’re contributing to these problems. And no matter whose fault it is, product management has to fix the problems.

In this post I give you a powerful tool for doing that – fixing the problem. And be sure to check out the infographic that goes along with this post.

Our Requirements Are Letting The Developers Down

Our primary mechanism for communicating with development – aside from having conversations with them, which you’re doing, right? – is via some variety of “product requirements document” – the written-down “Why?” and “What?” of a new feature or new capability in your product. This might be a document, or a wiki page, or even a post-it note.

I’ll use the term “requirement” in this article for this concept. But you might call these “features” or “feature specifications.” Or “Epics” or “User Stories.” (All these terms have problems, but that’s a topic for a different article.) Let’s just call them requirements or “product requirements” for now. I hope we can all basically agree on what that means, and nod our heads.

Product requirements are our “stock in trade” as product managers. But chances are we are not doing as good a job of writing and communicating these as we should. Or as we think we are. Resulting in the problems I mentioned above.

Let’s think about developers as people for a minute. Like all people, developers are motivated by what Dan Pink, in his awesome book Drive, calls the components of Motivation 3.0 – mastery, autonomy, and purpose. (The handy acronym MAP will help you remember these.) Of course, we PMs are driven by the same things.

Requirements and Mastery, autonomy, and purpose

What do mastery, autonomy, and purpose mean for software developers?

  • Mastery should be clear – it means that they are in control of their tools, and expert at using them. These tools are programming languages, of course, but also the engineering disciplines of technical design, architecture, problem-solving, and so on.
  • Autonomy is a little less clear. What does it mean for a developer – part of an engineering team, amongst other engineering teams, in a big company – to be autonomous? It means that they get to apply their mastery to solve problems in their own way, using their own expert skills. This explains why engineers are often so frustrated when product managers go beyond the “Why?” and “What?” in their requirements and start specifying designs.
  • Purpose is often the big problem for developers. We product managers have a good sense of our purpose. We want to help our customers have better, more successful lives and to achieve their business and personal goals. But if we’re not careful, it’s easy to lose the connection to this ultimate goal by the time a requirement gets to an engineer. Often the engineer is given a document that describes something the PM wants, but with no connection to the way it makes the customer’s life better. This significantly dilutes any sense of purpose that the engineer has, and consequently reduces their motivation to do it.

Summing up, engineers, being humans, are motivated by solving important problems – using their mastery of problem solving, architecture, design, and programming – in new creative ways – using their autonomy – so that they can improve customers’ lives – achieving a meaningful purpose.

If your requirements are not meeting the standard that helps them do that, they will be less motivated.

What can we do?

Part of the answer is use a good template. Templates are cognitive aids. They make sure we address all the necessary topics.

I’ve written in the past about the value of templates for our cognitive resource management. You might remember the “Impact Areas” template for product requirements or product feature specifications I described in the past.

There are a handful of common templates for writing requirements and related things. The best known one is INVEST – which is an acronym for:

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Small
  • Testable

But I’ve never felt that the INVEST acronym spoke to me as a person who is trying to solve problems for customers with my products. INVEST loses focus on the market problem, and instead takes too many implementation considerations into account.

I want to make sure my requirements addressed these issues head on. For example, the customer’s problem, the thing we’re trying to solve, needs to have pride of place. We must make sure that the development organization and product management are on the same page – that’s a meta-requirement. And the requirement is a lot more valuable if it includes acceptance tests. Developers, QA, and product management can quickly understand if the feature really solves the problem.

To capture all these insights, and a few more, I created a new “requirements” template. This template will enable you to communicate more effectively with the development team. And it has a great acronym!

The VALUABLE template

The VALUABLE Template InfographicMy VALUABLE template – yes, “VALUABLE” is the name of the template! – is focused on helping developers understand the value they are creating with their solution. Developers are humans and are motivated by solving real problems for real customers, so the VALUABLE template makes this explicit.

With VALUABLE, the market problem and the focus on the customer drive everything. And the implementation decisions are left to the developers and designers.

The “VALUABLE” acronym stands for:

  • V is for Valuable (yes, it’s a recursive acronym)
  • A is for Aligned
    • The feature is Aligned with company strategy and priorities
  • L is for Loved
    • The feature will be Loved by customers because it will do what they need and not cause them more problems
  • U is for Understood
    • The requirement is Understood the same way by engineering and product management
  • A is for Acceptance tests
    • The requirement has clear acceptance criteria so it’s easy to tell if the implementation delivers the desired value.
  • B is for Bounded
    • The development team and the product management organization both agree that this feature is “realistically achievable” by the current team. Note this doesn’t mean that we know exactly how long it will take or when it will be delivered. Just that we are confident we can deliver it soon enough for it to make a difference.
  • L is for Leverages
    • The feature Leverages our competencies and unique abilities, both technical and business
  • And the final E is for Expected usage
    • The requirement includes explicit and testable usage Expectations. These can be used to instrument the feature, and to monitor its usage by customers once deployed

Contrast with INVEST

The VALUABLE template addresses the goals of writing requirements from a vastly different place than INVEST.

While INVEST does have a V for valuable, it’s mixed in with other terms like Independent and Small and Testable. These are much more implementation-focused, and less appropriate for product requirements, per se.

VALUABLE is much more explicitly about customer value, about strategic alignment, and about coming to a common understanding with development. My template leaves out Independent and Negotiable, which are not necessary, and Small, which most interesting things are NOT. And it covers some things INVEST doesn’t – such as the “Expected use,” “Alignment with strategy,” and “Leveraging our competencies.”

What’s missing from VALUABLE?

No one template can contain everything, and some things are missing from this one. For example, it doesn’t explicitly mention that the market problem mentioned under V has been validated (although it is implied). And it doesn’t include my Impact Areas template – the I just didn’t fit in the acronym!

By design the template doesn’t mention anything related to a technical specification. I’ve explained why that can be demotivating for developers. If you think about the purpose of a requirement, to capture the Why? and What? of a feature, and not the How?, it makes sense. But there’s nothing limiting you from putting technical guidance into the requirement.

Using the template

How would I use this in practice? There are a few ways to use it.

  • You can use the template as the table of contents for your requirements.
  • You can check your requirements against the template as an acceptance test. For example, the Understood component reminds you that product management and development need to be on the same page. When both parties are communicating clearly, it reduces issues with the handoff of requirements.

Closing

I’d like to hear your feedback on this approach to writing better requirements that result in better deliveries from your development team. Download the infographic that’s perfect for hanging on the wall of your cube. Let me know via the comments if you think this can help you and your organization to be more effective.

Image Credit: “Communication” by Joan M. Mas. Copyright (c) 2007 Joan M. Mas, Attribution-NonCommercial 2.0 Generic (CC BY-NC 2.0) 

5 The Secret Product Management Framework

One of the most challenging questions about product management has been – in my experience – “What is Product Management?”

In this post, I share a simple model or framework to answer this question. I talk about this model with lots of people, but I’ve never explicitly written it down in a post. I’ve found the model to be very powerful in my career, and I hope it’s helpful to you.

(And if you read all the way to the bottom, you’ll find a nice bonus!)

We’re called “product” managers

We’ll start with a box labeled “Product.” (It’s in our name, right?) This is the part of the job that’s most obvious. I suspect most of what you’ve learned about product management thus far has revolved around “the product.” By the end of this post you’ll have a much better context for thinking about “the product.”

The first box in the Secret Product Management Framework

“Product” involves things like:

  • Requirements or user stories or features
  • Design, both visual and technical
  • Backlog
  • Agile development methodologies
  • Product manager =? Product Owner
  • Releases
  • And even roadmaps

And indeed, as a product manager “product” is where you spend a lot of your time, typically. But it’s not 80%. Maybe it’s 40%-50%, ideally. What do we do – or what should we do – with the rest of our time?

Our products solve problems for users

Here’s where things get interesting. The most fundamental thing to remember is that successful products solve problems for customers. I’m using the term “problem.” Business applications and products literally solve problems. Products for consumers can solve a problem, or they can address a desire or need. A consumer product like the Swiffer solves a problem – dirty floors. A consumer product like the iPod addresses the deep human desire for music. 1,000s of different product categories have addressed this deep human desire over the millennia.

I’ll use the term “problem” in this post, but you can think “need and desire” if you’re working on a consumer product.

A big part of our job is finding these market problems, customer needs and desires.

Since what our product does is solve a problem I’m going to rename the “product” box. Let’s call it a “solution.”

Products solve problems. So we have to find and validate problems to solve.

Market research

There are lots of ways to find market problems or customer desires, and I have several earlier posts that cover some of these techniques. A few useful approaches are:

  • Interviewing customers
  • Anthropology/ aka watching what they do
  • The Jobs To Be Done framework has a whole methodology for finding unmet needs of market segments

And note that this process needs to happen whether you’re talking about the product or an individual feature of a product. They all should solve problems.

Validation and feasibility

The other half of the “Problem” box is that we need to validate that the problems we found are worth solving. Will enough people pay for a solution that it’s worth our time to solve it? Indeed, can we solve it?

Finding and validating market problems is not a one-time thing. You need a continuous funnel of potential problems to solve with your product, or with a new product.

So you will constantly be out talking to “the market” to find and validate new problems. How much should you do this? Some product management experts say that product managers should talk to every one of their customers over the course of a year. And this is outside the context of a sales call!

Once you have this funnel of market problems coming in through this research, there’s a process of deciding which problems to attack. Which ones should you create solutions for. There are a lot of ways to prioritize, as I’ve described in previous posts.

The story so far

Summarizing, we find market problems that need solving, then we create solutions to the best of those problems.

But there’s one other very important product management function.

  • We need to find and acquire customers
  • We need to get people to buy our solutions.

Now we need to take our solution to market.

“Go to market” is the part of the product management process where we:

  • Define who is a good prospect, so that Marketing can go out and find those people
  • Make sure the sales people know what to say to those people when they find them

Go to Market Challenges

The challenges you’re addressing in the go to market phase are:

  • How do our prospects find out we have a solution to their problem?
  • Who are the right customer/prospects to target?
  • How do we find them?
  • What do we say to them when we find them?
  • What’s the best way to communicate with them?
  • Why should they buy our product instead of something else?

The Secret Product Management Framework

And that’s the Secret Product Manager Framework:

  • We find market problems, create solutions, and get customers to buy our solutions

Why is it “secret?” I’ve never seen product management described like this, so if anyone has done it, it was secret to me. Many people do talk about these components separately, but not tied together in this way.

How to talk to your parents about what you do

One of the big strengths of this model is that you can use it to talk to non-technical people about what you do.

(Don’t say you’re the “CEO of the product” – they won’t know what you mean, and they’ll think you’re full of yourself)

Try this instead:

“I find market problems, create solutions to those problems, and take the solutions to market.”

Everyone understand problems, and solutions, and customers, whatever their background.

Three takeaways

How can you start using this information right away?

  1. It should be your mantra. “I find market problems, guide the creation of solutions to those problems, and take the solutions to market.”
  2. It’s a good way to describe what you do. It will differentiate you from a lot of product managers who cannot give you a concise description of what they do. And it will help your thinking and help you change your mindset.
  3. Use it to help guide your activities. For example, the problem you’re solving imbues everything. Your work, at bottom, is not about the product, it’s about the customer and what the product does for them, how it solves their problem. Whether you’re talking to customers, prospects, or engineers try to put the feature or feature request in the context of a customer problem. One simple change is to say “you” instead of “we” when talking to customers about your product. I.e., “Our product has feature X” is wrong. Say “Your problem Y is addressed by our feature X.”

Bonus Video

For a longer explanation of the Secret Product Manager Framework check out the “What Is Product Management?” video, from my (still in production) Secret Product Manager Handbook series.

Keep in touch

Let me know in the comments what you think about the Secret Product Manager Handbook.

And don’t forget to sign up for my email list!

1 2 3 … 13
>