01
Jan 16

2016 – More Hardcore Product Management Ahead

Calendar, by Joy (CC 2.0 license)

Calendar, by Joy (CC 2.0 license)

The turning of the calendar itself has no real meaning, but it does give us a chance to reflect on what’s gone before, and what’s ahead. In my last post I reviewed the topics we covered in 2015. This post is about where I’ll be focusing in 2016 in terms of becoming a more skilled product manager, and in helping others achieve that. I already “practice what I preach” on all those topics, of course. But there’s always room for improvement, and as I’ve mentioned lots of times, getting more effective at product management has a huge ROI.

Systems

But instead of focusing on that goal this year, I’m going to focus on a system for being a better product manager. This approach is inspired by several writers and speakers I heard this year, including James Clear and Dilbert cartoonist Scott Adams (on his blog and on on Tim Ferriss’s great podcast).

The idea is the system is what gets you to the goal. You still have the goal (maybe), but you pay attention to the system. These other guys explain it better than I do – for example, James Clear illustrates the difference between goals and systems like this:

  • If you’re a coach, your goal is to win a championship. Your system is what your team does at practice each day.
  • If you’re a writer, your goal is to write a book. Your system is the writing schedule that you follow each week.

In 2016 I’ll be working on my system for being a more effective product manager. As my new and updated system components unfold, I’ll report back.

Deliberate practice

The other big focus for me this year is “deliberate practice.” Deliberate practice is a key part of Kathy Sierra’s “badass” concept, although I didn’t go into great detail on in my badass-related posts.

If you want to become better at something, you have to practice – it’s true of skiing, it’s true of photography, it’s true of playing a musical instrument. And it’s true of professional careers as well – surgeons practice a lot, and so do lawyers. And practice is not just “doing the job.” As Kathy Sierra says in her book Badass:

Only a specific type of practice makes perfect, and in the science of expertise, it’s known as “Deliberate Practice.”

James Clear says, building on Kathy Sierra’s description:

Deliberate practice is when you work on a skill that requires 1 to 3 practice sessions to master. If it takes longer than that, then you are working on something that is too complex.

There are examples in the literature of doctors performing deliberate practice, and of course top musicians do a ton of it. But I haven’t heard of a pedagogy for product management that uses deliberate practice. It seems worthwhile to focus on this for a while, both for myself and for the product management community as a whole.

Some examples that have come to mind so far:

  • Making phone calls to stakeholders – this is actually something I’m not as skilled at as I’d like to be. Once I’m on the phone I’m fine, but it’s more of an effort for me to pick up the phone than it should be. So I think deliberate practice will help me with this.
  • Entering defects – this is something we all have to do as product managers, and I’ve actually done quite a bit of practice on this one.
  • Various situations where deliberate practice will take the form of role playing: breaking bad news to a customer, telling a sales person that the product can’t do what they just promised a prospect, breaking the news of a schedule slip. Those are all bad situations, but it will probably pay off to do some practice on how to make the best of good results as well – writing an effective company email to share an exciting customer success, for example.

I will develop a set of these small product management activities to practice, and then determine the forms that the practice will take. And then do the practice myself over the course of the year. It should be very interesting. And I suspect my skills will be much more developed at the end of the year.

 


31
Jul 15

How Badass Are You At Finding And Validating Market Problems?

How to avoid having a “solution in search of a problem”

You have to become badass at finding and validating market problems to have a successful product business. This post will help you assess where you are now, and where you need to focus to get (even more) badass.

There are three main top-level activities for product managers:

  1. Find and validate market problems
  2. Create solutions to the problems
  3. Take the solutions to market.

And by now you know which of these I think is the most important. (Hint: #1.) Because if your product isn’t a solution to an urgent and pervasive market problem, no one will buy it.

There are many techniques for finding and validating market problems. They involve extensive interaction with customers and prospects to elicit problems, pains, needs, and desires using open-ended questions. (That is, you can’t just ask “What are your big problems?”) This is followed by analysis of what you’ve heard to surface and identify problems. Then those must be validated to determine which are valuable to solve, and which align with your organization’s abilities and business goals. I’ll get deeper into those techniques in a future post.

How Am I Doing?

In this post we’ll focus on framing the process and assessing how you’re doing. (Inspired by Kathy Sierra’s Badass ideas, if you’re keeping score.) Here are some questions you can ask yourself – answer honestly – to gauge your process for finding and validating market problems.

Process

  • Do you engage with a large part of your customer (and potential customer) base regularly to find unmet needs, desires, and opportunities?
  • Do you use techniques like open-end questions and direct observation of customers, rather than simply asking them what they want?
  • Do you have a process for aggregating the multitude of conversations to detect the “weak signals” that indicate problems you can solve?
  • Do you meet with customers separately from sales activities?
  • Do your prioritization criteria explicitly take into account whether a feature helps solve a validated market problem?

Outcome

  • Can you clearly state the market problem that you are solving and how your solution addresses it?
  • Do customers understand and agree that they have the problem?
  • Have you validated the value of solving the problem, the size of the market for the solution, and that your solution can be profitable?
  • Can you state how your solution is superior to or more desirable than that of your competitors, including doing nothing?

Obstacles and Challenges

Like any worthwhile activity, the process of finding and validating market problems is difficult. And it’s time consuming. You need to spend time “outside the building” talking to and interacting with the market. There are a number of other challenges you may face:

  • You may have difficulty getting “permission” to get outside the building to observe prospects and customers. Or you might only be “allowed” to visit customers when helping sales.
  • You don’t have time to visit or talk to customers because you are being pulled in too many directions.
  • You have a technology that people (inside the company) are convinced is a product, but which does not solve a market problem.
  • The amount of learning you get from any individual customer or market interaction is usually small. It requires many such interactions to start to surface the weak signals that indicate significant market problems.
  • There will be a lot of back and forth between your ideas for solutions, problems to be solved, the market you want to attack, and the technology you can bring to bear.
  • It is hard to find customers to interview; you are not sure where to start. This is especially true for startups that don’t yet have a customer base.
  • Some customers only want to talk to you about how existing features can be improved or new features they want. This is legitimate feedback, but often does not reflect a deeper underlying new market problem that will enable you to grow sales or expand your market.

Summary

Every other step in the product lifecycle depends on having important and valuable market problems to solve. Most everything else you might do as a product manager is meaningless if you’re building a solution without a problem:

  • Roadmaps
  • Requirements
  • Strategic alignment
  • Win/loss
  • Competitors
  • Sales
  • Go-to-market
  • Etc.

Remember:

“People pay you for a solution to a problem.”

Therefore, to have a successful product, you need a process for continually finding new problems – both big and small – to solve for your customers and prospects.


29
Jul 15

Do You Want To Be a Badass Product Manager?

My last post was about a basic product management framework. (Find and validate a market problem, create a solution, take it to market.) Someone said, “OK, that’s fine, but how do you actually do those things?” I will be creating a series of posts that to help you figure out “How am I doing?” in these three areas. I’m using Kathy Sierra’s “badass” ideas as the organizing structure, as you’ll see when I get those posted. In the meantime, I thought I would talk a bit about the “badass” concept itself.

When people ask about “books on how to be a good product manager” I always recommend Badass by Kathy Sierra. Or indeed, anything by Kathy Sierra, including her old blog “Creating Passionate Users.” (CPU is inactive now, but the old posts are still as compelling as ever).

First, the idea is not to get your users to be badass at your product. It’s to get them to be badass at their thing, using your product. People get excited about their thing, not about your product except insofar as it makes them better at their thing.

But there’s a process to becoming badass at a thing, whatever it is. This is so important to product managers because your product can help them get badass – or it can get in their way. Most very successful products do the former!

For an introduction, I recommend watching Kathy’s “Creating The Minimum Badass User talk from the 2013 Business of Software conference. Then, go buy the book. The video is one of the best spent hours you’ll have as a PM, in my opinion. The book is concrete guidance for how to make it happen with your product.

Some people have told me they found the book difficult to follow. I think watching the video helps a lot. There’s so much new (or at least different) thinking that’s coming together, you might need to hit it multiple times. But here’s my super-simplified version of the badass approach.

  • There is a path to mastery and you should tell your user this and help them understand it. That is, they’re not going to be badass overnight, but it does happen, and if you follow the path, you can get there.
  • You should give lots of good examples of mastery of the thing, and make sure bad examples are shown in a way that the lizard brain can’t interpret as good. Bad examples are terrible for learning, because our dumb brains don’t know the difference between good examples and bad examples.
  • The path to mastery has inevitable obstacles, that everyone encounters. You should warn your users in advance that they’ll hit these roadblocks, so they don’t feel they are more stupid than other people. Then help them out of the jam if you can.
  • Give your users intermediate “I Rule!” moments on the path to keep going. These can take lots of forms: A new skill, a deeper understanding of their domain, a challenge met and overcome.
  • The concepts of “flow” and “deliberate practice” are critical. Make sure at any given time that the user is challenged, but not too challenged.
  • The more you can treat your user as a human (i.e., using conversational language, using visuals, chunking information, plus many more) the better you will be at getting past the brain’s crap filter. See Kathy’s “Crash Course In Learning Theory” for a quick overview of these concepts.

Kathy uses a number of metaphors to help you think about these ideas, including:

  • Snowboarding (which sucks on Day 1, but is better on Day 2). The good examples are all around you on the slopes, typically. And the bad examples are clearly bad – people falling on their butts!
  • Photography (long path to mastery, but you can make progress on intermediate skills, and if you keep doing this, you’ll keep getting better).

I’m so interested in this framework because not only do I make products, but I want to help you become badass product managers. So I have to use these ideas.