The Product Kata

A while ago, I was introducing the Kanban Kata by Hakan Forss to a team that was struggling to meet their deadline. They had failed twice before and their jobs were in jeopardy. Implementing Continuous Improvement and Kata helped the teams create better processes and remove bottlenecks. I was the coach that took them through the motions that Hakan eloquently teaches, which is based on the Toyota Kata by Mike Rother. The team was able to solve their own problems by getting into a habit of learning. They shipped on time, and kept their jobs.

As I was working with the Kanban team, I realized that I was using this process to create successful products. This framework was just much clearer than the way I was going about it in my own head.

Before I tell you how to apply this to products and Product Management, let’s first start with the fundamentals.

Toyota Kata is a Continuous Improvement framework that creates the habit of improving by focusing on learning. It’s teaches you how to analyze problems and then create small experiments to solve them. This is the secret sauce that made Toyota great. Every team member was responsible for improving the company’s processes. With thousands of people flexing their problem solving muscles daily, they were able to reduce waste while delivering the highest quality.

The 4 steps of Toyota Kata are fairly simple.

Management will set the challenge while the teams grasp the current condition and establish target conditions.

Next, you follow the Coaching Kata to plan the steps to get to the next target condition. The coach is a team member who asks the the following questions during every meeting. The whole team then answers and plans the work.

This is a very quick overview, but If you want to learn more about Kata you should visit Mike Rother’s page or read his book (which I highly recommend).

Hakan took these processes and applied them to improving the Kanban, which ultimately improves you work. I’ve been taking these principles and applying them to building software products. I call it Product Kata.

Continuous_Product_Improvement

Following the Product Kata helps us take small steps to learn about our customers’ needs, and start solving their problems faster.

If you’ve been at one of my talks, you may have heard about a disaster project I built a few years ago. I was working at an ecommerce company that sold items that celebrity “sellers” endorsed. At the beginning of the year, management tasked my team with building a Seller Portal, where all of the celebrities could manage their own stores. We set out to interview a few of them and find out what they needed.

For the next quarter, we built a portal for them and released it. Long story short, no one ended up using it. We really didn’t understand their needs from the short time we spent interviewing them. We built them a complicated tool that was bloated with useless features. We ended up rebuilding the portal and eventually found something that they wanted to use.

So how would we have done this if we used Product Kata? Here’s an idea of what that might look like:

First, we would have understood the direction.

It was incredibly costly for us to manage our seller’s stores. A quarter of our employees were spending upwards of 15 hours each week on the phone with the sellers to answer their questions. Our management gave us the challenge of figuring out how to make our sellers self sufficient. Now, a note about challenges – they are lofty goals. Sometimes we’ll never reach this goal exactly, but we’re going to get as close as we possibly can.

Direction/Challenge: Make our sellers completely self sufficient in managing their stores.

But how do we get there? The first time we built this portal, we jumped to the first solution we could think of too quickly – build them software that does everything. We didn’t stop to consider that there are a million unknowns in reaching that lofty goal. We didn’t know what the sellers were calling about now. We didn’t know their technology habits. We didn’t know which ones called more than others.

When you run the Product Kata, you recognize that these questions are just obstacles that need to be addressed to get to your next target condition.

So what would be our target condition? Since we’re not sure how to get to the final result yet, what is one step towards it that we can take. We can start with reducing the number of calls a week, which would help free up our staff.

Target Condition: Sellers call office less than twice a week.

At the present, they were calling more than twice a week but we weren’t sure exactly how much. This was our first obstacle. In order to improve something, you need to be able to measure the change.

Obstacle: We’re not sure how often sellers are calling now.

CPI_-_1

 

The first thing we need to do is answer this question quickly. We can ask the staff who answer the seller’s calls to measure how often they call for the next week. Right now, we think they’re calling about 4 times each per week.

Step: Staff measures how often sellers are calling by counting calls over one week.

Expected: We believe they are calling about 4 times a week now.

When planning experiments, you want to reduce the time between learning so you can move quickly to your target conditions. Steps shouldn’t take more than a week where possible. If they do take longer, try to break them down.

 

CPI_-_2

 

What did we learn? In reality, the curators were calling 7 times per week, almost double what we thought. Woah.

Learned: Sellers were calling 7 times per week.

We then measured our current condition again and found out nothing had change. We hadn’t met our target condition yet so we asked ourselves what obstacles are we facing now, and continued experimenting.

Current Condition: Sellers were calling 7 times per week.

Is the target condition met?: No.

We learned more about why the sellers were calling and which were the most frequent asks. Now we were able to start solving their problems.

CPI-_5

We tackled getting them to call less for revenue by providing them with a weekly email. We found out they wanted a more frequent update, especially when they had a lot of sales going during that week. Most of the time, the sellers were not putting new sales out but every once in a while they had a booming week where they launched a bunch of new products. They wanted to know the return on them every day so they knew which ones to promote more to their audiences on social media.

Current Condition: Sellers are calling 5 times per week.

Obstacle: Have sellers call less for revenue.

Step: Staff would provide the sellers with a weekly email about their revenue. Measuring amount of calls abotu revenue over two weeks.

Expected: The sellers will stop calling for revenue all together.

Learned: Sellers want revenue updates every day so they can promote the best sellers on social media.

Have we met our target condition?: No

It’s also important that every step you take, you also say how you will measure its progress. A step with no measurements can’t tell you if you are improving.

CPI-3

Providing them with their revenue every day through email cut down the phone calls to three times a week. We continued experimenting like this until we got it down to once a week, freeing up many hours for our staff to work on other things.

CPI_-_4

If you look at these steps, you will see that we weren’t building new features for the sellers. That would have taken a lot of time, and we wanted to learn quickly. The biggest mistake we made at our first pass of the portal was including monthly revenue, but not daily revenue. Every seller was pissed off by this, but it took four months to learn. With Kata, we learned this in a matter of three weeks, and we were able to include it in a wildly more successful future version.

Learning is one of the most important parts of the product development cycle, but too often we skip over these steps and just rush into creating products. When we work with Product Katas, we can address each thing we need to learn and then incorporate that into the final products. Not only is this a faster way of working, but we have a much better shot at getting the product right the first time.

This was an incredibly brief blog post and I didn’t have the space to go over all the nuances with planning Product Katas. If you have any questions please comment below and I’ll answer them. If you want to learn this way of working, reach out to me at melissa@produxlabs.com.

Creating Effective MVPs coming to NYC!

Creating Effective MVPs Full Day workshop is coming to NYC on July 16, 2015!

Full Day Workshop on July 16, 2015 in Manhattan (9:30am – 5:00pm)

Only 20 tickets available! Buy Tickets Now

Traditionally there is usually little validation before work begins on a new product; and teams end up wasting time building something that no one wants. User Experience suffers and companies are left with products and features that remain unused. MVPs; or Minimum Viable Products; can boost a product’s user experience exponentially. Teams who implement MVPs correctly will learn more about customers, waste less time, and deliver usable solutions faster. But, MVPs are wildly misunderstood today, and setting up one wrong can deliver false results.

In this workshop you will learn the ins and outs of creating MVPs and how to introduce this concept into your companies successfully.

What you will learn:
In this hands on workshop, Melissa will teach you framework for creating effective MVP experiments while practicing the fundamentals. You’ll also learn:

  • How an MVP is one of the most effective tools you can use to learn about your customers
  • How to formulate problem and customer hypothesis
  • How to align product experiments with your KPIs
  • How product development teams, marketing, and the business can work together in this process
  • How focusing your teams on experiments rather than features can save your companies years of development costs
  • How to iterate on feedback from your customers to plan experiments
  • How to integrate Minimum Viable Products into your Product Roadmaps

Who should attend:
Product Managers, UX designers, developers, stakeholders and team leads.

Lean Product Management Manifesto

If you want to read the story behind the Lean Product Management Manifesto, you can find it here.

Over the past few months I have been working with people in the Lean and Agile community to figure out how we can communicate the benefits of a Lean approach to Product Management. I expect this to evolve and change as we continuously integrate these principles into our own practices and learn. I welcome your feedback and contributions. I hope we can get together in an open space one day to discuss and improve it. Thank you to Adrian Howard, Corey Innis, Chris Matts, Tim Lombardo, Rob Liander, Wes Royer, and Alberto Anido for your reviews and help!


The Lean Product Management Manifesto

We are uncovering better ways of creating valuable products for customers by doing it and helping others do it. Through this work we have come to value:

Customer problems and needs over internal requirements
Data driven experiments over preconceived solutions
Customer problem roadmaps over feature roadmaps
Idea generation and collaboration over solution mandates

While we value the things on the right, we value the things on the left more.


 

Customer problems and needs over internal requirements

We believe that the best products are ones that solve customer problems. Product Managers spend a lot of time gathering requirements from inside the company and getting features approved by business stakeholders. As Lean Product Managers, we understand that the most important information comes directly from our customers. Thus, we should direct our efforts at exploring customer problems and needs, while keeping in mind our business goals. While we need to know the internal stakeholder requirements, we spend more time outside of the office, talking to our customers face to face and determining what value we can deliver by providing solutions for their problems and needs.

Data-driven experiments over preconceived solutions.

We believe in finding customer value by running small experiments. Product Managers spend much of their time thinking up and documenting unvalidated features. As Lean Product Managers, we focus on running experiments using MVPs, getting solid data from customers, and then making decisions on product strategy. As we experiment and learn, our product decisions are based upon fact and not speculation.

Customer value roadmaps over feature roadmaps.

We believe that effective product roadmaps need to focus on customer problems and the delivery of value from solving these problems. Product Managers plan roadmaps off speculation, slotting in features to be built because they think it is what customers want and need. These roadmaps focus on building unvalidated solutions, and usually don’t include adequate amounts of time to do effective customer research and run experiments. As Lean Product Managers, we understand that we need a plan that reflects our process of discovering problems, experiments, and building validated solutions. We create problem roadmaps that communicate customer value by experimenting on features that are aligned with the company’s goals and KPIs.

Idea generation and collaboration over solution mandates.

We believe that exceptional products are not built by the efforts of one person, but by great teams. Product Managers usually come up with feature ideas on their own and then dictate solutions to the designers and developers. Lean Product Managers understand that the best ideas can come from many different sources, including customers, designers, and developers. We solicit ideas from others, and work collaboratively with designers and developers to determine product strategy.

These are a set of guidelines I have used to improve my Product Management practice and help others do the same. These principles should not be blindly followed. If you do plan to use them, adapt them for your specific organizations and situations. And, as always, improve upon them as you learn and practice.

The Story Behind The Lean Product Management Manifesto

Setting the Stage

In the past few years, I have had a lot of people come up to me and ask about Product Management (lean, agile, waterfall, whatever) and what makes a “good” Product Manager. They’ve also asked for resources. A lot of the resources on traditional Product Management tend to focus on story card grooming, lots of feature specs, and playing politics with the business. While these are necessary, I don’t see them as the epitome of a “good” Product Manager. So I decided to formulate my thoughts around the values of a exceptional Product Manager in a tweet:

I got a lot of interesting feedback, had some great discussions both on and offline, and I’ve iterated on it since them. Thank you to everyone who contributed their ideas and feedback! That was the whole point of putting it out there in it’s half assed state – to see what the community thought and hear others’ stories quickly. Boom, Lean.

Surprisingly (to me) most of the feedback I got was “don’t write a manifesto”. Saeed Khan wrote an article on this. I agree with most of his points, but would like to address two important ones.

First, why am I calling it “Lean” Product Management manifesto and not just Product Management manifesto?

Excellent question! If you were to ask five Product Managers from different companies what they did, you would get five different answers. You’d find patterns between some of them, such as being able to groom story cards, write specs, and interface with the business. The problem is that we tend to focus more on the documents and features produced than the value those things bring to customers.

This is where Lean comes in. Lean’s core principles are found in delivering value, respecting people, customer pull, and reducing waste. These are things that should be applied to Product Management. To shift our focus from deliverables to value for customers. This isn’t meant to be a list of all the principles and techniques of Product Management, but simply where we should start focusing our attentions more in our daily work.

Second, and most controversially, why am I writing a manifesto?

Honestly, I don’t care what you call it. If you hate the term manifesto, you can call it “Lean Product Management Guidelines” or “Those things that we should probably value but we’re not.” I chose the term manifesto because I modeled it off the Agile Manifesto, and hey, people actually refer to and listen to that (and debate it, which I hope you’ll do with this).

I’m not writing this to say “you must always do Product Management this way, it’s a religion.” These are a set of guidelines I have used to improve my Product Management practice and help others do the same. These principles should not be blindly followed. We are all humans who are capable of thinking, and you have the ability to use these (or not) as you see fit. Adapt them for your specific organizations and situations. And, as always, please improve upon them as you learn and practice.

And with that, here’s The Lean Product Management Manifesto.

What Makes a Great Product Manager?

It’s a question I get asked often by my students, clients, and people in the community. What is it that separates the good Product Managers from the best? What qualities in my potential candidates will let me know this person is the real deal?

To me, there’s one thing that stands between a good Product Manager and an exceptional Product Manager. It’s not wireframing. Not coding. It’s not communicating with developers, or sizing markets.

It’s the ability to kill feature ideas before they are built.

Wait, what? Shouldn’t it be the opposite of that?

Too many people think that a great Product Manager is the idea man. The visionary. The Steve Jobs. The feature god. This is just wrong. 

Ideas are dime a dozen, and anyone in a company has the ability to come up with a great idea. The biggest problem we face at software companies is that we have too many ideas. More often than not, we end up building most of them in hopes that something will stick. We spend countless hours creating feature after feature, and releasing it to customers with our fingers crossed. Then no one uses it.

It’s not hard to build things. It’s hard not to build things. It’s so hard to stop ourselves from getting overly excited about a potential feature.

A great Product Manager is the destroyer of bad ideas. She filters out the good ideas from the bad ideas by testing them early with customers. Then, she needs to be able to look the person who came up with the idea in the eye and say, “I appreciate the feature idea you came up with, but we have tested it and we should not build it. It would be a mistake to build it. Here’s why.”

This is not an easy skill. This idea person could be the CEO, the CMO, or the developer sitting next to you. More often than not, it’s yourself, which is the hardest thing of all. She needs to be ruthless, yet compelling and understanding. She needs to be a focused experimenter, who can test an idea cleanly. Then, she has to communicate the results to a wide array of people who came up with these ideas in a way that is easily digestible.

When a Product Manager builds everything that comes her way, the product ends up feature heavy and complicated. Yet, so many Product Managers do this because they are afraid to challenge their managers. Managers, if you want to hire a game changing Product Manager, you need to be open to the fact that your feature ideas are going to be dissected and questioned. And most likely, destroyed. This should be built into your culture, so that no one feels like they cannot disagree with you. Otherwise, you will end up with a worthless product, and some very unhappy and frustrated people.

Product Managers – if you want to go from being good to great, take a lesson from Grumpy Cat. Get comfortable saying, “No”.

grumpcat