All Posts by nils

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

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

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.



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


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

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.


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

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.


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


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)