Changing the Conversation about Product Management vs. UX

pm ux fight

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.

Hi Fly: A Lean Airline Story

hifly

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.

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.