Writings

Thoughts and information on Product Management

­
23 October, 2016

Stop Blaming the User

By |Uncategorized|1 Comment

I’m finally going home from a long business trip and I’m very excited. But my experience with United Airline’s customer service this morning completely killed my good mood.

They keep blaming me for their mistake. It’s a story I know well because I see it so commonly in Product Management too.

When I was booking my return ticket from London to Newark, the cheapest option was for something called “Mixed Cabin”. I could fly Business Class between London to Dublin and then Economy from Dublin to Newark. Since I had to get up at the ungodly hour of 5am to get to the airport, I thought that could be a nice treat on my first leg. So I booked it.

Here’s what my reservation looks like from a few minutes ago:

Imagine how surprised I was when I checked in for the first leg on Aer Lingus and they gave me seat 27B. “There must be a mistake,”,I thought. So I told the flight attendant that I was booked through United in Business. She replied, “We don’t have Business Class on any of our flights.”

What a bait and switch! United is selling me something that doesn’t exist. It’s only a one-hour flight, so I’m not going to hem and haw all day, but I wanted to get to the bottom of it. So, I tweeted… because that’s what you do when you’re angry. What happened next, pissed me off more than the switcheroo.

The customer service agents considered this my fault, and acted like it wasn’t a big deal.

 

As someone who doesn’t work for an airline, how am I supposed to know that Z class doesn’t exist on Aer Lingus? When you purchase your ticket and it says “Business”, that’s what you expect. I don’t think I am wrong for being upset; yet United is telling me I am. If I went to a restaurant and ordered the duck, the waiter wouldn’t say “I’m sorry, we actually meant steak when we wrote duck. Here’s your steak, deal with it.”

I’m not telling this story to complain about United (well, maybe that’s part of the reason). The moral of my story is this: I see product teams commiting this classic mistake all the time. Product Managers love to blame the user. If the user doesn’t understand something, they are just stupid. If the user won’t tell us what they want, they are difficult. If they are calling to complain, they are ungrateful.

This is a dangerous mindset, yet it’s so prevalent. “Users don’t know what they want,” is the battle cry of Product Managers all over the world. It’s their excuse not to talk to them, because what could a user tell them that they don’t already know?

The problem isn’t with the user. It’s with you.

The Curse of Knowledge Bias makes you forget that as a Product Manager, you have more knowledge than the user when it comes to your product. You can’t understand how they could find something difficult when you can do it so easily. Users become just a thorn in your side, and if they went away and took all their complaints and wishy-washy answers to your questions with them, you could build THE BEST PRODUCT IN THE WORLD! You forget that if users went away, you would be out of business.

Recently, I was training Product Managers at a very large company. I always start off with a major focus on the user and trying to uncover their problems. We did a Product Kata workshop to help demonstrate this. The idea behind Product Kata is to take a step back, figure out what you need to learn, and create a test or step to learn it. In this case, the teams had to create a “paper pizza” for the user. Chris Matts helped out by being our user. They had 45 minutes to sell Chris $10 worth of pizza. Everyone immediately jumped in and started asking him “What do you want?” He answered, “I don’t know what I want. I like these things…”

After a while, everyone hated Chris. Someone even said, “I am going to pivot my pizza business to martial arts because Chris better learn to defend himself.” That was pretty funny, but also a prime example of the problem. This happens all the time in real life. The reason people were getting frustrated is because they were asking Chris, “What do you want?”

It is not the user’s job to know what they want.

It‘s their job to know what problems they have. You need to understand how to question them about their context, problems, and needs. If you cannot do this well, you will end up getting frustrated with the user. When I interrupted the teams from running around like chickens with their heads cut off, I asked them “What do you need to learn?” No one had even thought of that question (even though I just taught them they should!). They just set to work to immediately build a bunch of crap hoping he would buy it.

When they stopped and realized they needed to learn the context in which he was eating the pizza, they were able to solve it within 5 minutes. After 30 minutes of wasting a bunch of paper pizzas.

Sound familiar?

It is easy to blame the user, but it is so dangerous for organizations. It leads to culture of disdain for our customers and whole lot of arrogance on our part.

In large companies this is particularly true. When you have layers of bureaucracy, very long-term employees, and a million different departments separating you from the user, it’s easy to forget about them. Product Managers in these companies say, “We can’t talk to the user, that’s the job of another department.”

There are always ways to learn more about your customers, even if you have different departments. For example:

  1. Go talk to the customer service team. When I was working with a client at the beginning of the year, we had trouble finding users to talk to. We could easily talk to people who already signed up, but we couldn’t get in touch with people who dropped off. Customer service could, though. We talked to them about what we were trying to learn, and gave them questions to ask. Then, we met with them weekly to go over what they learned from the users. This helped a lot. If you can, even go so far as to take customer service calls a few times a month.
  2. We designed ways to learn more from our user in the above case, as well. We implemented things like Qualaroo to get feedback from users when they were dropping off. They were allowed to type whatever they wanted in a box asking, “What’s stopping you from signing up today?” We got thousands of responses and learned the biggest problems.
  3. When I was working for a B2B company, I was told I wasn’t allowed to talk to users because we would disturb them. I was the head of UX there. I fought for that ability, and was allowed to go with a sales team member. In that interview, I was able to prove that what we were building was not what the user expected. I brought that back to the team, and it gave me more buy in to keep doing more interviews. We ended up setting up a little feedback group of some willing customers and gave them access to tools earlier than others, and some extra hands on support. This proved invaluable for our discovery methods.

It’s easy to forget that the reason our businesses exist is because someone is buying our product. Someone. Not a nameless persona full of stats, but actual human beings. Human beings have feelings and needs. When I am paying United for a service and they are telling me, effectively, that I’m wrong, I feel frustrated. I feel wronged. That leads me to start to look for their competitors. I’ve bet you felt that too on just about any airline. How many times have you tweeted that they don’t care about you? Felt that they don’t care about their customers in general?

It’s the same for your users. How do they feel when you do this? Blaming them is not the answer. I never said it was easy to talk to users, but it is the only way you can understand and build empathy for them. This is what makes a good Product Manager. If you don’t want to talk to users, get another job. If you’re willing to give it a shot, remember to take a step back and put yourself in their shoes.

14 July, 2016

What is Good Product Strategy?

By |Product Management|2 Comments

“What is your Product Strategy? YOU NEED A STRATEGY.”

When I replay this scene in my head, I can hear the CTO very audibly yelling (slash pleading) with our product team. He was on edge. We had been experimenting towards a very concrete goal for two months, and had made a lot of progress. We had learned so much about what was preventing users from signing up on the site, and it was a lot clearer which direction in which we should be going. BUT we still had to test our ideas.

This didn’t sit well with the CTO because in reality he didn’t want a strategy, he wanted a plan. He wanted a list of what we were going to build, and when we were going to build it. He wanted to feel certain about what we were doing when we all came in tomorrow, so he could measure our progress based on how much we built. It’s not his fault though. This is the way we were taught to think about Product Strategy.

Most companies fall into the trap of thinking about Product Strategy as a plan to build certain features and capabilities. We often say our Product Strategy are things like:

  • “To create a platform that allows music producers to upload and share their music.”
  • “To create a backend system that will allow the sales team to manage their leads.”
  • “To create a front of the funnel website that markets to our target users and converts them.”

This isn’t a strategy, this is a plan. The problem is that when we treat a product strategy like a plan, it will almost always fail. Plans do not account for uncertainty or change. They give us a false sense of security. “If we just follow the plan, we’ll succeed!” Unfortunately, there is no guarantee of success here. (I wish there was, our jobs would be SO much easier!)

These product initiatives aren’t bad, they are just communicated at the wrong time and with the wrong intentions. When we lock ourselves into planning to build a set of features (ehem, Roadmaps), we rarely stop to question if those features are the right things to build to reach our goals. We stop focusing on the outcomes, and judge success of teams by outputs.

We need to have a plan but the plan shouldn’t be “build feature x.” Our plan should be to reach our business goals. We need to switch from thinking about Product Strategy as something that is dictated from top to bottom, and instead something that is uncovered as we learn what will help us achieve our objectives.

Product Strategy is a system of achievable goals and visions that work together to align the team around desirable outcomes for both the business and your customers.

Product Strategy emerges from experimentation towards a goal. Initiatives around features, products, and platforms are proven this way. Those KPIs, OKRs, and other metrics you are setting for your teams are part of the Product Strategy. But, they cannot create a successful strategy on their own.

We need a few core things for our Product Strategy to be successful:

Vision: The vision is your high level, ultimate view of where the company or business line is going. In large corporations, you want to narrow this to the business line or customer journey. In smaller companies, this will be your company and product’s overall vision. Think long term here, and keep it qualitative. This is a good chance to talk about competitors, how customers will see you, and ambitions for expansion.

Challenge: The challenge is the first Business goal you have to achieve on the way to your longer term vision. Which area of your customer journey or funnel needs to be optimized first? It’s communicated as a strategic objective that helps align and focus your team around a certain aspect of product development. This can be qualitative or quantitative. Try to keep these still in broad, high level terms. This one is the hardest for me to personally wrap my head around, but check out the example below for some clarity.

Target Condition: The target condition helps break down the Challenge. Challenges are made up of smaller problems you need to tackle along the way. These are set in terms of achievable, measurable metrics. When you set a target condition, your team shouldn’t know exactly how to reach it tomorrow. They should have a good idea of where to start looking through.

Current State: This is what the current reality is compared to the Target Condition. It should be measured and quantified before the work starts to achieve the first target condition.

 

Product Strategy Animation

These all contribute to something called “Unified Field Theory”, which is explained very nicely here by Bill Costantino and Mike Rother from Toyota Kata. When we are building products, we have a threshold of knowledge. We cannot start on Day 1 and exactly plan to reach our vision. There are too many unknowns and variables. Instead, we set goals along the way, then remove obstacles through experimentation until we reach our vision.

This is best explained through an example, so we’re going to use Uber. Let’s pretend you’re a Product Manager working on the platform that allows drivers to sign up.

Please note: I have no affiliation with Uber so this is a guess as how they might line up their strategy if they chose to use it. The vision is from a statement their CEO made in an interview. The rest I am improvising for the example.

Vision
The CEO has stated that the company’s vision is to make Uber the cheap and efficient alternative to both owning a vehicle and taking public transportation. (He really said this in an interview, but everything after this is hypothetical).

Challenge
So if we understand the Vision correctly, Uber wants people to use them as their sole source of transportation. They would first want to look at why other people are taking other transportation methods now instead of Uber. They may go out and interview people and find that in certain cities where Uber isn’t as popular, there is a very long wait time to get a car. They would compare this to other problems and determine how big it is in comparison. Let’s say it’s the biggest challenge at the moment.
So the first goals they may want to tackle is decreasing the wait times in cities where it’s exceedingly long. Let’s say anything over 10 minutes on average is too long, and we want to decrease that down to 5 minutes or less because we’ve seen in cities with those wait times, people are 80% more likely to use Uber.

This is now our Challenge: Decrease wait times in cities where it is over 10 minutes to less than 5 minutes by January 30, 2018.

Target Condition
As a Product Manager, you now want to figure out what is causing that long wait time. The problem in this case might be that there are not enough cars to serve that area. So our metric we care about now Acquisition of new drivers.

Our goal for our team should be measurable and achievable, something like: We want to onboard at least one driver for every 50 people in each city by January 30, 2017.

As the Product Manager responsible for the onboarding process for new drivers you would be tasked with contributing to that acquisition. You would first measure how many drivers per people in each city you currently have (Current Condition), then find the obstacles that are preventing new drivers from signing up today. Next, you experiment to remove each obstacle until you successfully hit your goal. The Product Kata explains how to do that.

So let’s step back and take a look at all that:

(You can download a blank copy of the Product Strategy canvas here.)

As a Product Manager, you don’t have control over all these numbers. The vision is set by CEOs, CPOs, Boards, and other C-Level Executives. The challenge is set by the next level of management (VP of Product for Each Journey or Business Line).

Direct Managers help their teams set effective Target Conditions. At the beginning these may need to be handed down from management. As teams get used to this way of working, the managers and team can work together to set them.

Once these four items are set and communicated, the team can start applying the Product Kata method to figure out how to reach the goals. It’s the Product Manager and their team’s responsibility to determine the user problems and other obstacles standing in the way of achieving that Target Condition. Then they experiment to solve them.

This aligns everyone around a strategic goal and vision. Every level of the portfolio has their objectives. Teams are held accountable for their progress towards the goal they are responsible for reaching.

Now you have probably looked at this and said “well this isn’t a product strategy, it’s a business strategy.” Yes, this does come off looking like a bunch of business objectives, but isn’t that why we built a product? To reach our business objectives? Product Management is the art of solving your customer’s problems to reach your business objectives. If you’re not doing both of those things, your product is just a fancy piece of code for show.

The next post will be on how to format your Product Roadmaps around these strategies, and how to communicate with stakeholders to encourage experimentation.

 

26 May, 2016

How to Educate Stakeholders

By |lean, Product Management|0 Comments

There is one question I always get during every Product Management workshop:

How do I convince/teach/educate stakeholders to work this way?

stakeholders

We need to change this perception.

The class has bought in on validation before building, a focus on problems, and defined metrics. They can see the value, but they are afraid they will return to work and get shot down. Often they do. Unfortunately, there’s really not much you can do about it as a Product Manager. Your job is not to educate and train your entire company on this way of working. It’s to create valuable products for your customers and your business.

The way I approach stakeholders is the same way I approach customers – empathize. Stakeholders aren’t at this company to make your life miserable. They are there to do a job. So start to ask questions and learn about them. How are your stakeholders measured for success? Usually they have concrete goals they have to hit. Learn what those are. What are your stakeholders problems? How can you solve them?

When you start empathizing with stakeholders, you realize that the things they are demanding or requesting relate back to assumptions. These assumptions are based on what they think will help them solve their problems. Become a Product Manager for your stakeholder. Explain how this way of working helps them achieve their goals. This has worked very well for me in the past, even with really difficult stakeholders.

Now, if you stakeholder still doesn’t understand this way of thinking and is not bought in, you need to change your approach. If you are having meetings where you are asking for feature requests, stop. Stop it right now. The meetings you set with Stakeholders and the way you run those meetings set the tone for your relationship. If the purpose of all your meetings are to gather requirements (aka feature requests) and communicate deadlines, this is the way your Stakeholders will view you – as a place to dump their requests and get status updates.

Flip those meetings on their heads. Use them to learn more about their business and the problems they are currently trying to solve. Give status updates on what you are currently learning and the goals you’re working towards, not hard dates on shipments. Changing the conversation allows your team to come up with the best solutions, instead of building just what the stakeholders or customers ask for.

Remember, you’re job is not to teach or educate. You need to explain clearly why you do certain things, but that explanation is enough. Start to draw the line. Work with your manager on approaches and tactics so you have support from above.

Have you tried all this and it’s still not working? I’m sorry. That happens a lot. Honestly, until stakeholders, managers, and team leaders want to change, they won’t. You can encourage them to start coming to the same conferences and workshops you do. That will help build a shared context. Many of my workshop attendees leave and say “I wish my manager was here for that.” If you are a manager, I would take that sentence to heart. You’re never too busy to spend time educating and improving yourself. But, if none of this works, you have to make a tough call.

Last night I was talking to James Royal-Lawson who put it the best way I’ve heard yet. When someone asks how to convince their managers or stakeholders, he replies:

What do you want to do with your career? Do you want to go into training and change management? Or do you want to be awesome at your job? If you don’t want to go into change management, find a job that allows you to be the best you can be. If you want to do change management, then we’ll talk.

If you want to change a company, that’s going to be where you spend all of your time. This is what I do every single day. You have to be ready for it. It’s a long hard role. If you want to be the best Product Manager, then try some of the above, or find a place that will let you grow.

13 May, 2016

Ignoring Innovation: Lessons from Kodak

By |lean, lessons learned|2 Comments

In 2007 I joined an innovation swat team at Cornell in the Johnson Graduate School of Business. It was called the Business, Science, and Technology Initiative (known to the cool kids as BSTI). We were working with Kodak to come up with a completely new product that would appeal to our age group, the early 20s.

For the next two years our team of nine would meet biweekly to research, experiment, and learn more about our fellow peers. I remember walking into the room on our first day. We sat down to write science fiction stories about how the world would look in 10-15 years. I really had no idea how this would pertain to Kodak or innovation at all. Were we going to build robots? Surprisingly our stories weren’t crazy fantasies. We were pretty level headed and realistic people.

We broke down the stories into motivations, desires, fears and needs. Then we made a motivational profile. We zoomed out to a 176 need and want statements, and then zoomed into 20 key ones that we would work with.

Here’s some of them:

  • I need to feel in control of my image.
  • I want to know what others think about me. (Later proved not to be a good idea by the infamous Juicy Campus)
  • I want to be able to act my age and not worry about how it will affect my search for internships and jobs.
  • I fear being judged or punished for one aspect of my identity.
  • I want to minimize inaccurate data/reports that are easily accessible.
  • I want to be able to be in different social circles and not have one circle judge me because of another circle.
  • I want to know what people expect from me.
  • I don’t want my identities mixed/mashed between my different social groups.

To understand these needs, you have to also understand the timing of 2007. We were one of the first classes that were completely on Facebook from day one. We were constantly checking status updates, broswing people’s profiles, and uploading every possible photo from the party the night before. I recently had to detag thousands of photos of my friends who now have babies, so I got to fully reminisce about how many photos we actually took back then.

I remember starting Cornell taking a digital point and shoot camera with me to every party. A few months later, I was using my stupid 1.3 mgpx flip phone to take most of my photos. Then, the first iPhone came out. It changed the game. Now we had better quality cameras in our pockets every day. Photos piled up. More people started getting iPhones. We were constantly connected to Facebook all day. Texting, monitoring, uploading.

Then a year later we got a reality check – internships. Everyone was applying for work over the summer. We knew the recruiters would be looking for drunken Facebook photos. These were the horror stories spread throughout school. You’d see people crying, “Lehman Brothers turned me down because I had a beer in my hand!” Security cracked down. We started filtering who could see our profiles. We were more careful about what we posted online. Those who weren’t could be seen crying around campus.

All this played into what we were doing for Kodak. After figuring out our own needs and wants, we went out to interview our peers and get their perspectives. We each ran interviews to learn more about them and empathize. We came out with similar results, but the key focus was really around managing our identities in an online world, enhancing your image through photos, and community management.

The key needs became:

  • I need to gain as much relevant information as possible about my outer network for reducing the social “cost” of interacting with my outer network and for efficiently recruiting new friends to my inner circles.
  • I need to gain as much relevant information as possible about my relevant relations in order to impress them.
  • I need to be able to control my image and images, and when crossing the intended boundaries, they irrecoverably self-destruct.

After understanding the needs, we went into brainstorm mode to figure out what Kodak could do. We spent time talking with their team to understand their mission, their technologies, and their business. Over the next few months we came up with ideas, got feedback from peers, and refined them. Finally, we finished a presentation for Kodak in which we suggested many ideas, including the following:

  • Build advanced camera technologies into a phone that can produce high quality photos.
  • Build software into that phone that would allow you to do basic editing of photos to make them look better.
  • Tag the photos with GPS location so they can be uploaded to albums easily and shared with friends or individuals.
  • Tie photo albums to events in your calendars.

There were other aspects we included about mood boosting and event hosting (which you’ll find in our write up called Market Driven Innovation) but these were the core elements I remember very vividly.

We were pretty excited about what we came up with. We could see the value for both Kodak and ourselves. I left that last day energized and waiting for a new product to come out. Then months passed. We heard nothing. Years passed. Again, nothing. I checked in at one point and heard they were evaluating it and waiting for a team to work on it. Years later I heard from former employees that point and shoot camera technology has been more appealing at that time to the management than phones.

Five years after we started in January 2012, Kodak went bankrupt. Four months later, Instagram was acquired by Facebook for $1 Billion. In 2013, Kodak emerged from bankruptcy. Two years later, and seven years after our suggestions, Kodak launched a phone. You probably haven’t heard about it.

There’s a few things I’ve learned from working with Kodak that make more sense to me now after working with many companies trying to innovate:

Having an innovation team doesn’t make you innovative.

When you treat innovation like a standalone part of the business, you lose your competitive edge. You’re not able to act on the ideas you come up with. Waiting for buy in, resources, and budget will push faster moving competitors ahead of you. Innovation has to be woven into all your product development teams. It should be something they think about on a daily basis, and are ready to start acting on immediately. Execution is 9/10th of the battle.

Don’t get distracted by what you’ve always done.

Kodak fell into the common trap of doing things the same way they have always done. While they were enhancing their point and shoot cameras and film, the market was going full steam towards phones. There were definitely people at Kodak who recognized this (and spun up programs like BSTI), but corporate structure prevented those on the ground floor from getting good ideas to market.

Failing to recognize market signals is a great way to kill a company.

Your customers can provide an eye opening way perspective. You just have to listen to them. The research we did showed pretty vividly where the market was going. Many companies don’t even incorporate these learnings into their product development timelines, instead falling into an endless loop of building things no one wants. Getting outside the building can change your perspective. But, make sure you are the ones going outside. It’s more powerful for the people building the product and making the decisions to hear it themselves.

In reflection, I learned a lot through this project. It just took me a while to realize it. It ties into the premises that I teach today about talking to your customers and building products that solve problems. If you’d like to read more about the entire project, we wrote an article called Market Driven Innovation.

5 May, 2016

Finding the Truth Behind MVPs

By |Uncategorized|1 Comment

If you’re interested in learning more about MVPs, I’m running a one day workshop in Paris on June 14, 2016. More information here.

A Successful Start

I learned about Minimum Viable Products like 99% of other Product Managers – through The Lean Startup by Eric Ries. When I happened upon the book and Eric’s method, I thought, “YES! This is what I’ve been searching for. This makes so much sense.” Testing products before you build them? What a novel idea! I was excited. I was energized! I was now going to build things that mattered to my customers.

Frankly, this came at the perfect time for me. I was tired of building products that no one used. Watching and waiting for the numbers to go up in Google Analytics, only to be let down again. It was getting old. My team and I spent months building products we thought would be successful, only to be disappointed. When I had the chance to try the MVP approach on a new product, I jumped on it.

The CEO of our ecommerce company approached me with a new product idea that was going to increase engagement and sell more items. He wanted to implement a Twitter-like feed so that the celebrities, who sold products on our site, could also post about their lives. This idea was prime for testing. It was so ripe with assumptions: “Do our customers want to hear about what are celebrities are up to directly in our platform? Will this sell more items or increase retention?”

I went to the engineers and asked them how long it would take to fully implement this idea from scratch, the way our CEO was proposing. With rough estimates, I went back to our fearless leader and told him “This is going to cost us $75,000 to fully build, and we’re not even sure our customers want it. I can prove in a week with $2,000 if this is going to move the needle.” Just like that, I had buy in.

Within one week, we proved this was a terrible idea. A week after that we found a different solution that increased clickthrough rate threefold on our products. We also doubled conversion rate. The whole company was hooked, and we were allowed to keep experimenting. “Great,” I thought, “everyone can see the value of this! It’s a no brainer.”

Eventually, I moved on to another job. I was excited about bringing the concept of MVPs to this team as well. Honestly, I was kind of shocked that everyone in that company wasn’t using them already. Did they just not know about this wonderful witchcraft? I was so confident that everything would go exactly as it had in my previous company.

“We Don’t Do That Here”

When the words “Minimum Viable Product” left my mouth for the first time, the reaction in the room was quite different than I expected. You would have thought I recited every curse word in the English dictionary. Like I just busted out a Biggie Smalls song in the middle of the meeting, not bleeping out any of the colorful lines. They responded as if I had offended their ancestors. Finally the CMO broke the silence with, “We don’t do that here. We don’t ship terrible products.”

Over the next few years I experienced this same reaction countless times.

I’ve learned that Minimum Viable Products are widely misunderstood. Some people are afraid to try building MVPs because of preconceived notions. Others use the word so much that it’s lost all meaning. “We should MVP that!” has become a battle cry in product development that just means make it minimal, make it cheap, and make it fast.

How do people end up here? The story is almost always the same. Someone picked up The Lean Startup, had their mind blown, and said “We should do that here!” They saw a quick and cheap way to execute on a product without fully understanding what the purpose of an MVP was or how to make one well. In my particularly jaded company, a developer ended up creating a hack to test a new feature that broke every time someone went to use it. Customers were pissed. The company blamed it on MVPs as a whole, rather than sloppy development.

It’s not the MVP’s fault. The problems stem from misinterpretation of what an MVP is and from miscommunications along the way.

What is an MVP?

My definition of a Minimum Viable Product is the smallest amount of effort you can do to learn. When I teach this in workshops, I’m usually met with disagreement. “MVPs are the smallest feature set you can build and sell! Not just an experiment.”

So what is the truth? Is an MVP a product, a subset of a product, or just an experiment?

The Minimum Viable Product was first coined by Steve Blank and then made popular by Eric Ries in The Lean Startup. I went back to research how these two experts, and a few others, defined the term.

“The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on.” – Eric Ries, 2009

“Minimum feature set (“minimum viable product”) is a Customer Development tactic to reduce engineering waste and to get product in the hands of Earlyvangelists soonest.” – Steve Blank, 2010

“A minimum viable product (MVP) is not always a smaller/cheaper version of your final product.” – Steve Blank, 2013

“An MVP is not just a product with half of the features chopped out, or a way to get the product out the door a little earlier. In fact, the MVP doesn’t have to be a product at all. And it’s not something you build only once, and then consider the job done.” – Yevgeniy Brikman, Y Combinator, 2016

Confusing, yes? The one thing that was clear to me through this research is that the definition of an MVP has evolved. In the beginning, we talked about this concept as something to validate startup ideas. All these products were searching for product-market fit. I learned about the Concierge Experiment and Wizard of Oz in those days, which helped shape my definition and understanding. As I continued to use these methods as a Product Manager in enterprises and other more mature companies, I had to customize both my definition and the practice of building Minimum Viable Products. What I’ve learned is that you need both – the concept of experimenting and building a minimum feature set to be successful.

While there’s tons of dissent on the definition of an MVP, everyone pretty much agrees on the goal. The goal of an Minimum Viable Product is to rapidly learn what your customers want. You want to do this as quickly as possible so you can focus on building the right thing. So let’s get rid of the buzzword and focus on that premise. Let’s stop arguing about what an MVP is and start talking about what we need to learn as a company.

How and When to Learn

When we start off building a new feature or product, there are a million questions to answer. “Is this solving the customer’s problem? Does this problem really exist? What does the user expect to gain with the end result?” We have to find the answers to these questions before committing ourselves to building a solution.

This is why starting with a minimum feature set is dangerous. When you jump into building a version one of a new product or feature you forget to learn. Experimenting helps you discover your customer’s problems and the appropriate solutions for them by answering these questions. It also doesn’t end with just one experiment. You should have multiple follow-ups that keep answering questions. The more you answer before committing yourself to the final solution, the less uncertainty there is around whether users will want or use it.

Once you have proven that a user wants your product, it’s time to investigate a minimum feature set. Now we can start to find a product that is marketable and sellable, but also addresses the user’s needs that were uncovered through experimentation. Delivering this product to market as fast as possible is the ultimate goal, so you can get feedback from customers and iterate. But, you have to be careful to deliver a quality product, even if it’s tiny. Broken products do not produce value for your customers, only headaches. Any version of a product that does not deliver value is useless.

How does this look in practice? In one SAAS company I was working at, we had to create a new feature that would help our customers forecast their goals. We were given input by the customer’s sales team from their conversation with the customer. After reviewing the information, we knew we had to learn more.

We met with the customer to understand what they were looking for in this forecaster. Once we thought we had a good grasp of the needs, we built them a spreadsheet and dumped their current data into it. This took us less than a week. We presented the spreadsheet to the customer and let them use it for a week before getting their feedback. We didn’t get it right the first time, or the second, or the third. But, on the fourth iteration, we were able to deliver exactly the results the customer was looking for. We did the same process with a few other customers to make sure this scaled.

While the spreadsheet was providing immediate value to some of our customers, we didn’t have the resources to do it for all of them. So, we had to build a software solution. We started exploring the Minimum Feature Set, using the feedback we received on the spreadsheet. There were plenty of other bells and whistles the customers wanted, but we paired it back to the essentials in the first version. We spent a few weeks getting the first version to work and include the most important pieces. Then we turned it on for the clients with the spreadsheet to get their feedback. After iterating a few times, we began selling it to others.

This process is will help your company find problem-solution fit. If you are creating a new feature or a new business line that solves a different problem for your user, this method can help ensure you’re building the right thing for your customer. But what if you have a mature product and are not starting from scratch?

Experimenting in Enterprises

Many enterprises today are introduced to the Minimum Viable Product by consultancies who propose creating an entirely new product from scratch. This is may not be the best idea. When your company already has product-market fit, you have already built a product that customers are using. You do not need to rebuild your product, you need to improve it. The methods should to be adapted for this case.

Something that sets these two methods apart is the goal. When searching for product-market fit, you want the user to adopt and probably pay for your product. This is not always the goal when improving existing products. It could be to improve retention or increase engagement with certain parts of your product. Whatever you decide your goal is, it should be clear to the team and informing all their decisions.

Once the goal is clear, you again focus on learning. What do you need to learn before committing to a solution. Write out these hypotheses on what you think will move the needle, and then design a Product Experiment to test it. You don’t have to create an entirely new product. Maybe you will find out a new product is necessary while experimenting, but that should not be the end goal.

A company I coached wanted to increase their conversion rate across the site. They already had a popular ecommerce subscription product with thousands of users. Traffic was coming in, but users were not converting as much as projected. Nothing had moved the needle when it came to offer testing. They dug into the sources of where great customers were coming from and found that many came through referrals. But, only a few people were actually sending referrals. Through user research we discovered two main reasons why: they didn’t know they could actually send referrals, and they were not sure what the referral gave their friends.

The team decided to tackle the first problem with the hypothesis, “If we let users know clearly that they had referrals available, they would send them.” The first experiment involved showing a pop up that encouraged users to send referrals when they next logged in to the site. Referrals sends went up 30%, leading to an increase in conversion rate! They did not have to implement a whole new program here; they just had to create ways to make it visible.

This team continued to dive into problems around conversion. They learned that the top three problems on the direct-to-site experience were:

  1. Customers were not sure how the service worked.
  2. Customers wanted to know what specific items came in the subscription.
  3. Customers were not sure why the product was priced higher than competitors.

The next step to solving this problem was to see if they could deliver value and learn at the same time. They created the hypothesis, “If we give users the information they are searching for in the sign-up flow, they will convert more.”  They also wanted to learn which questions people would click on most to see which problem was the strongest. They planned a simple way to get people the information they needed while signing up: adding a few links into the sign-up flow, echoing the questions back to users. When the links were clicked, it showed a pop up  explaining the answer to the question. At the end of the week of building and testing, they could see the experiment increased conversion rate closer to our original goal. They also learned that showing the information about what exactly came in the subscription was the most important thing. The team continued to learn what was preventing prospects from signing up, and systematically answered those questions through experimentation.

Caution Ahead

One mistake companies make when dealing with Product Experiments is keeping them in play once you have learned. These features then break and cause problems for your users. You are designing to learn and move on, not to implement something that will last forever.

With the team above, they learned that the information they provided was helping prospects answer their questions, but not enough people were seeing that solution. After experimenting more, they learned that a more robust solution would be needed.

It was time to start planning a sustainable solution that incorporated the learning from the experiments. Moving away from Product Experiments to the next phase is not an excuse to stop measuring. This team was still releasing components in small batches, but those batches were complete with beautiful design and a more holistic vision. After every release, which happened biweekly, they would measure the effect it had on conversion and test it in front of customers. The feedback would help them iterate towards the product that would reach the conversion rate goal.

Chris Matts has eloquently named this the Minimum Viable Investment. He’s also pointed out that you should not only be looking at improving your user facing products, but the infrastructure that helps you create those products quickly. The team above is also improving their site architecture to experiment faster while waiting for test results. I introduced the Product Kata to teams improving their products to help them find structure through Product Experiments and Minimum Viable Investments.

Learning is the Goal

One of the scariest parts of this process for companies is releasing things that are not perfect. It’s important to balance good design with fast design and good development with fast development. The best way to do this is getting UI designers and developers to pair together. After defining what the goal is for the iteration or experiment, sit down together and talk through ideas on how to execute. If we design in a slightly different way, is it just as useful to the user, but easier to build? Prototype together. Sketch together. Work side by side and talk about trade offs the whole time. This is how good teams move quickly and avoid rework.

By learning what the user wanted early, I’ve avoided countless hours of rework and throwing out features all together. This is why it’s so important for teams to experiment, whether they are B2B or B2C. Give the product teams access to users. I’ve seen fear in companies that their employees will say or do things that will upset users. If you teach your product teams the right way to communicate and experiment, this will not happen. Train the teams in user research. Don’t release experiments to everyone. Create a Feedback Group with a subset of users. Build infrastructure so you can turn on experiments and features just for smaller group. These users will guide you to create features that will fit their needs.

I dream of a day when I can walk into a company and mention “MVP” and not hear, “We don’t do that here.” While the definition of Minimum Viable Product may work us into a tizzy, the goal behind it is extremely valuable for product companies. If you’re having trouble implementing these practices inside a company, try leaving out the buzzwords. Use terms like experimenting and focus on the premise. Learning what your users want before you build it is good product development. Make sure when you do invest in a feature or solution, it’s the right one.

This post was originally published on InfoQ on April 18, 2016.

17 January, 2016

Changing the Conversation about Product Management vs. UX

By |Uncategorized|23 Comments

If you had to pick one, would you rather be a Product Manager or UX Designer?

I’m both.

You can’t be both. We need to put you on the right team.

That’s not your job.

I had no idea what a Product Manager was when I started at Capital IQ, almost 10 years ago. I didn’t even apply for the job. A friend told me they were hiring, and I asked if there were any roles for people like me — engineers who liked Photoshop. After talking to a few people, I was told I’d make a good Business Analyst (their term for Product Manager, I’d later learn). The combination of business and analysis sounded intriguing, so I jumped on the offer.

My responsibilities were gathering business requirements, specifying features, passing the specs off to engineers, mocking up the interfaces in Photoshop, user acceptance testing, gathering feedback from customers, user research, and managing the scope. The company was far from Agile or Lean at the time, but I didn’t know any better. I loved it. Solving problems and watching them come to life was way better than my other options — supply chain management or coding.

Four years later at OpenSky, I heard the term “User Experience Designer” for the first time. My boss announced we were hiring a Director of UX. Apparently my role as a Product Manager was not the same as a UX Designer. What?! I was blindsided. The UX Director was now in charge of all the interface designs and mockups. He made it sound like a good thing. “Congrats! You don’t have to do any more wireframes.”

But I loved designing. I loved creating flows that solved problems.

The developers were finally participating in the process too. We were sketching together, incorporating each other’s ideas, and pairing on iterations. When the new Director of UX started, most of that went away. Now there were hand offs. I was still testing product ideas, but I didn’t get to participate in what that looked like for the user.

Quickly I realized this was not the role I wanted. I left to become the Lead UX Designer at another company. Now I had the opposite problem. I wasn’t allowed to participate in feature decisions. Those were made by the Product Managers. I was just the person who designed them. I felt like Lucy and Ethel in the chocolate factory, trying to wrap up all these features in pretty designs. The conveyor belt never stopped.

lucy and ethel

I wish product ideas were chocolate so I could eat them.

I saw features become approved that didn’t relate to the feedback I was hearing from customers. When I tried questioning why we were building them, I was quickly shot down. Once I brought up the idea of making an MVP. Wrong move. I got a few death stares and was told “We don’t do that here”.

I was confused. If I did both Product Management and UX, and I was good at doing both, where did I fit in?

There’s some UX in your PM.

When I compare these roles, I see responsibilities that are clear cut. For example, prioritizing feature requests has typically been led by a Product Manager.

Then, there are responsibilities that are murky. Who makes personas? At one company I’ve seen it as the PM, at another UX, and at another Marketing. Who owns User Research? Same story.

If you read different job descriptions, you’ll start to see a lot of overlap in major responsibilities:

 UX vs PM

When I was writing the Product Management curriculum for General Assembly, we had trouble here as well. There were weeks dedicated to topics some saw purely as UX — personas, research, wireframes, etc. But these are all necessary for Product Management too.

It’s not about roles, it’s about skills.

I’ve found the definition of roles matters less than how a company operates. Highly collaborative teams have Product Managers and UX Designers who assign each other tasks based off what they need for the project. Whoever is best suited in that moment to do it, does it. They agree on this. Sometimes the UX Designer might be doing research, other times the PM, and hopefully, more often than not, they’ll both work on it together. Everyone can move forward without feeling territorial.

Companies need to realize that both Product Managers and UX Designers are important, but what’s more important is that these two people can make decisions together. Product Management with no User Experience Design creates functional products that don’t make users excited. User Experience Design with no Product Management produces delightful products that don’t become businesses. If these two roles are not sharing responsibilities, then you will have a disconnect in both your team and product.

If we change the conversation to skill coverage instead of role definition, it becomes clearer. Do we have all the skills we need on this team to validate and execute a product idea? If we have a Product Manager who cannot wireframe, let’s hire a UX Designer. If we have a Product Manager who does UX Design, let’s hire a Visual Designer. If we truly want to iterate and get to market faster, we need to focus on limiting our team size. Having too many moving pieces only slows us down. Limit the scope of the work and make more teams rather than adding on roles or people to one.

My knowledge of UX Design makes me a better Product Manager and my knowledge of Product Management makes me a better UX Designer. It makes me better at creating products that delight users and solve their problems. There’s a lot of people like me out there. Find them. Hire them. Don’t make them choose.

29 December, 2015

Hi Fly: A Lean Airline Story

By |Uncategorized|0 Comments

This past year I took six trips to London. Five of those round trip flights were on Norwegian Air.

I HATE Norwegian Air. Without fail, every one of my Norwegian Air flights were delayed at least 2.5 hours. But on one trip back from London, I got a surprising test message.

I had never heard of this HiFly airline before. I was incredibly skeptical but I needed to get home. The plane I boarded was a completely white, unmarked jumbo jet that looked like it came back through time from the early 90s. “Limited” entertainment system is laughable. There was no entertainment system. But I was pleasantly surprised to find they served us food and drinks, unlike Norwegian. Overall it was a decent trip home with a good book and some wine.

I had my second run in with HiFly in September when I was traveling back from England with my mother. I assured her it would be fine, even better because we would get free food and drinks. So she promptly dropped the sandwich from M&S and we boarded the plane.

After we took off I found out we would not be getting food on our eight hour journey back to New York. To say I was enraged is an understatement. Around hour four, I ventured back to ask the crew for some crackers in my best Oliver Twist impression. Luckily, the flight attendant was awesome and fed my mother and me a full meal in the back. While we were chowing down on airplane food, I learned the story of HiFly. And it’s genius.

HiFly is an airline for hire. Because their planes are unmarked, they can fly routes for all major airlines and private companies. When an airline like Norwegian is starting out, they don’t invest in new planes until they can justify the cost. So they operate at full capacity, with every jet being used at all times. If a plane needs to be repaired, they would have to cancel scheduled flights since there are no spares.

That’s where HiFly comes in. Norwegian would call in HiFly, sometimes with only hours notice. The flight team would assemble and fly into wherever they are needed to run the route. This allows Norwegian to keep the scheduled flight and not pay tons of fees in cancellation. It also greatly reduces the risk for starting new airlines.

In addition to saving the butts of new airlines, HiFly is also used to test new flight routes. For example, if United thinks that it should start servicing Buenos Aires to London, they would hire HiFly for three months and sell tickets for the route. At the end of the three months, they analyze the profitability of the route. If it is a good investment, they buy their own jet and establish the route permanently. If it’s not, they stop running the route and move onto something else. This is an airline MVP — the minimum amount of effort to test the value of a new offering.

Many people think lean is about being “cheap”. It’s really about mitigating risk. Even though these airlines have to shell out a hefty amount to hire HiFly, it completely dwarfs the amount of money it would take to create an entirely new route. They would need to buy a plane, hire staff, support it with marketing — and that’s just the beginning. Lean is about lowering your risk of failure by testing your ideas early. When United hires HiFly for a new route, they aren’t investing millions of dollars in this idea before they know people want to fly it.

But, just like with product experiments, there needs to be a certain standard of UX to make the experiment valid. Norwegian screwed up our flight by not providing HiFly with enough food for the flight. This would spell disaster if it happened on a route they were testing. But in our case, Norwegian was just covering their butts so we couldn’t ask for fees, not running a product experiment. On test routes though, the airlines are sure to provide everyone on the plane with a comparable user experience to a regular route.

Even in gigantic, heavily regulated, bureaucratic industries, it is possible to mitigate risk through experiments. HiFly has built a very profitable business by being the MVP of airlines.

22 July, 2015

The Product Kata

By |Uncategorized|11 Comments

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

 

SIDEBAR: The first three iterations of here we weren’t experimenting because we still did not have data around the current condition. We had to clarify exactly where we are what problems needed to be solved before we moved on. This is a step most people miss when they start experimenting. They will jump in without making the current condition very clear.

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.

8 July, 2015

Agile and Lean Chat with Dave Gray

By |Uncategorized|0 Comments

A few months ago I had the opportunity to chat with Dave Gray on my experiences using Agile and Lean for the book he is writing, tentatively named “Principles of Agility”. I thought it was a great discussion and left me with a few blog posts I’ve been meaning to write about the subject (coming soon!). If you don’t have time to watch the whole video, I’d suggest skipping ahead to the last 15 minutes.

 

15 June, 2015

Creating Effective MVPs coming to NYC!

By |Uncategorized|2 Comments

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.