User Stories Are Better Than PRDs

Posted on by
6

In the previous post, we focused on how product managers share customer knowledge with engineers. We discussed how user personas are an effective way of  telling the customer’s story. We also looked at how some teams share artifacts (videos, audio, written reports) from usability tests to help communicate customer pain points. But I left out a critical mechanism for how product managers share customer knowledge with engineers – the user story.

Historically (let’s say before the internet), product teams wrote Product Requirement Documents (PRDs), long documents that outline every nook and cranny of a product. Some teams still work this way. But many have moved to writing product requirements in the form of user stories. User stories have the following format:

As an actor, I can take some action for the following benefit.

Let’s look at each of these parts in turn. First, the actor. More often than not, I see users stories start like this, “As a user …”, but this is pointless. The point of the actor is to take on a perspective. For example, if I’m writing user stories for an event site like eVite or Facebook events, I might have stories that begin with:

  • As an event host …
  • As an event invitee …
  • As an event attendee …
  • As someone who cannot attend an event …

This tells engineers who will be using the functionality. It might seem trivial, but I can’t tell you how many times the wrong functionality was built because the actor was misunderstood.

Next, let’s look at, “…I can take some action …” this is the part of the user story that most resembles what goes in a PRD. For the same event site, we might have:

  • I can invite my friends to my event
  • I can RSVP to an event invite
  • I can map the location of the event
  • I can view photos from the event

This tells engineers exactly what new functionality is needed. Finally, let’s look at “…for the following benefit.” More often than not, I see this part of the user story just left off. It’s true, you technically don’t need it, to know what to build. But by leaving it off, you lose just about all the context of why you are building what you are building. Continuing with our event example, we might have the following benefits:

  • so that I can easily manage who is attending.
  • so that I can let the host know whether or not I am coming
  • so that I can easily get to the event.
  • so that I can live vicariously through the people who did attend.

This event example is pretty straightforward. But in more complex products, the benefit can often clear up misunderstandings about why you are building specific functionality. It also helps to keep the focus on the actor. You aren’t building functionality just because, you are building functionality to serve a need.

User stories don’t just communicate to engineers what they should build, they communicate why. This is a unique advantage of user stories over PRDs. Yes, there’s nothing stopping you from writing the why into your PRD. And yes, many people write bad user stories, where they forget to clearly define the actor or leave the benefit off altogether. But let’s focus on what we, as product managers, can control.

Suppose I create a great PRD. It doesn’t just explain what the engineers should build, but it provides all the requisite customer knowledge to set the context. Let’s say it ends up at 15 pages. I hand it off to my engineers. What happens?

They might read it through once. After that, they probably will refer to screenshots, or skim for relevant technical bits as they build. What do they ignore? All the reasons why.

Now let’s suppose that instead of writing a 15 page PRD, I write 50 user stories. I hand them to my engineers. What happens? They may read through the list of 50 once. That’s fine. Because what happens next, they start with the first user story and ignore the rest. But if each and every user story, communicates information about the actor, explains the desired action, and the benefit to the user, as the engineers implement each story, they have the why right there in front of them. They never lose sight of the content of why they are building what they are building.

Looking back at some of the concepts discussed in the prior two posts, a user story is a great example of a boundary object. A boundary object facilitates knowledge sharing between two groups that have little overlap in their own knowledge.  A product manager has a wealth of customer knowledge, an engineer has a wealth of technical know-how, a user story allows a product manager to communicate bite-sized knowledge about the customer to the engineer, within the context of what they are building.

Everybody wins. Moral of the story: write good user stories, clearly specify the actor, and pay special attention to the benefit.

Sharing Knowledge: From Product Manager to Engineers

Posted on by
3

This is the second post in a four part series on Sharing Knowledge in Product Management. The first part looked at sharing knowledge from customers to product manager. This part examines from product Mangers to engineers. Part three will examine from engineers back to product managers. Finally, part four will look at from product managers back to customers.

Assuming all goes well, between customers and the product team, this is still only the beginning. The product team has to share this newly acquired knowledge with the engineering team in the form of product requirements. For many product managers, the synthesis of customer knowledge into product requirements is an intuitive process. However, many engineers want to give feedback and be involved in the product definition phase, but they lack the wealth of customer knowledge that the product team has.

To further complicate the matter, engineers and product managers share little common knowledge and often approach problems from very different viewpoints.  Product managers are well versed in the whole business and are primarily focused on solving a customer problem. While engineers may also be interested in solving a customer problem, their primary focus is on developing a sound technology solution. These interests do not always line up.

Hislop’s (2009) boundary classification helps to understand these differences. He defines three types of boundaries between groups: syntactic boundaries, semantic boundaries and pragmatic boundaries. In the simplest cases, the boundary between product managers and engineers is merely syntactic. Both groups share the same interests, approach the problem the same way, but merely lack common knowledge. Often times, overcoming this boundary can be as simple as translating from the customer jargon to terms the engineering team can understand.

Other times, however, the boundary can be more complex. In some instances, both the product team and the engineers share the same interest, meeting the customer need, but interpret the data differently, meaning a semantic boundary separates the two groups. This typically happens when the data is incomplete. For example, many companies evaluate web traffic to guess at their customers’ intent. Product managers will often come up with a very different interpretation of this data than engineers. Engineers have a wealth of technical knowledge about the product, while product managers have a wealth of knowledge about the customer. Each knowledge base influences their interpretation of the data.

For syntactic and semantic boundaries, product and engineering teams use a variety of boundary objects to help span theses borders. Hislop (2009) explains that boundary objects can help to develop the area of overlap between the two communities.  Product teams often write persona documents, fictional customer snapshots that convey the customer need, the context in which the need occurs and enough information about the customer, that they are transformed from an abstract idea to a concrete (if fictional) person. When a disagreement or open question arises, both the product and engineering team can use the persona to shift their focus from their own perspective to that of the fictional customer. It helps both groups step outside of what they know and think like their customer.

Product teams also run usability studies, recorded sessions where the customer tries to tackle a problem by using the product, while being observed by the product team. Video footage of these sessions is often very effective at sharing rich customer information with engineering teams. Because engineers are so close to the product, they work on it day in and day out, it is easy for them to lose perspective on what is easy and what is hard. At times, nothing short of video evidence will help in convincing an engineering team that a customer does not share the same level of product knowledge as they do.

In rare cases, a pragmatic boundary may exist between product managers and engineers, meaning they don’t even share a common interest. This can happen when a company has not set a clear goal or vision and different members of the organization have defined the customer problem differently or favor different solutions. In these cases, it often requires input and facilitation from other areas of the company for product and engineering teams to overcome this boundary.

As was the case between customers and product managers, engineers must also have competence trust in their product team. They must trust that they have the requisite skills to correctly identify the customer problem and verify that the proposed solution is a suitable one. If the product manager gets this wrong, it comes at a high cost for the engineering team, as their work goes wasted. Similarly, product managers must be careful to retain this trust and not abuse their position to promote their own interests, but instead promote the interests of their customers.

In the next post, I’ll take a look at the flow of knowledge from engineers back to product managers. Stay tuned. Was this helpful? Please let me know what you think in the comments.

References

  • Cross, Parker, Prusak, Borgatti (2001) “Knowing what we know: Supporting Knowledge Creation and Sharing in Social Networks,” Organizational Dynamics, Vol. 30 No. 2 pp 100-120
  • Hislop, D. (2009). Knowledge Management in Organizations. New York: Oxford University Press
  • Newell, David, Chand, (2007) “An Analysis of Trust Among Globally Distributed Work Teams in an Organizational Setting,” Knowledge and Process Management, Vol. 14, No. 3, pp 158-168

Sharing Knowledge: From Customer to Product Manager

Posted on by
6

This is the first post in a two+ part series. I have content in mind beyond the first two parts, but want to gauge interest before deciding whether or not to continue. These first two parts are sections of a paper I wrote in a class called, “Creating and Sharing Knowledge” at Northwestern University. As a result, it’s a little more formal than my previous posts and includes citations to referenced material. I do think the material is very relevant to the world of product management and if you agree, I’ll continue to experiment with similar posts. 

In order for a company to launch a successful product, it must build a product that customers actually want. It has to fill a specific need, work within the context in which the customer has the need, and work in such a way that the customer can understand it. This requires that the company have knowledge of all of these factors before they decide what to build. How does this happen?

Hislop defines innovation as “the deliberate modification, or transformation, by an organization of its products / services, processes or structures” (2009, pg. 114).  He argues that innovation is primarily a knowledge creation process, but also includes the ability to search for external knowledge, the ability to apply existing knowledge to new contexts and the ability to combine knowledge in new ways. In the product discovery process, product teams may engage in any or all of these activities.

Customers rarely know what they want. They aren’t product experts. They don’t know the market. They may not even be clear on the specifics about the problem they are experiencing. A product team does two things during the product discovery phase. First, it clearly defines a problem that the customer is experiencing. Second, it identifies a suitable solution to that problem. In order for a product team to accomplish this, they must cultivate strong relationships with their customers. Cross, Parker, Prusak, Borgatti (2001) discuss four attributes of an effective relationship for sharing knowledge: knowing what another person knows, being able to gain timely access to them, willingness of the person to engage in joint problem solving and the degree of safety in the relationship.

Product teams must be aware that while customers do have some explicit knowledge about their problem and potential solutions, they just as often may be limited in their ability to define the problem, and quite often lack the product expertise to explore possible solutions. Product teams must combine customer knowledge with knowledge acquired through observation of the customer experiencing the problem. The team must combine these two sources of knowledge with broader market knowledge before exploring solutions. If the team doesn’t have access to customers, or the customers aren’t willing to engage with the team in problem solving, or either the team or the customer doesn’t feel safe sharing what they know or don’t know, this process will be hindered.

Similarly, Newell, David and Chand (2007) outline three different levels of trust: commitment trust, competence trust and companion trust. Commitment trust is trust that both parties will follow through on an agreed upon contract. Competence trust is trust in a person’s ability to complete a necessary task. Companion trust is the trust that develops over time as the result of a personal friendship. If a customer does not have competence trust in a vendor, they won’t be willing to spend the time required with the product team to help in the product discovery process. Similarly, the product team has to trust that the customer will honor their commitment to devote the time to this process. In situations where the product team has companion trust with a customer and both parties approach the product discovery phase as a partnership, the process works best.

In the next post, we’ll look at the flow of knowledge from product managers to engineers. Stay tuned. Was this helpful? Too formal? Please let me know what you think in the comments.

References

  • Cross, Parker, Prusak, Borgatti (2001) “Knowing what we know: Supporting Knowledge Creation and Sharing in Social Networks,” Organizational Dynamics, Vol. 30 No. 2 pp 100-120
  • Hislop, D. (2009). Knowledge Management in Organizations. New York: Oxford University Press
  • Newell, David, Chand, (2007) “An Analysis of Trust Among Globally Distributed Work Teams in an Organizational Setting,” Knowledge and Process Management, Vol. 14, No. 3, pp 158-168

Interesting vs. Meaningful

Posted on by
16

About a year ago, I was struggling. I was the CEO of a technology startup. We were going through some tough times, but we were okay. I wasn’t.

Looking back, I realized that my struggle was that while I was interested in what we were doing, it simply wasn’t meaningful to me. Being a CEO is a tough job. I didn’t fully appreciate that until I became one. I’m not afraid of tough jobs. In fact, I run marathons because I believe the struggle is often the point of the journey. But it has to be meaningful. Otherwise, it’s just struggle for the sake of struggle.

I’ve spent the last several months thinking about what I want to do next. I’ve talked to a lot of people. I’ve considered a lot of different things. Nothing felt right. Until recently.

Over the past two months, i took the time to answer the question, what is meaningful to me? It wasn’t easy. I didn’t do it in one sitting. I refined it over time. I imagine I’ll continue to refine it over the rest of my life. But today, I have a list of 13 values or virtues that I believe shape who I am today.

Five of them might be universal: gratitude, self-compassion, curiosity, authenticity, and growth or challenge. Over the past four years, I’ve deliberately focused on cultivating these traits. For some, like curiosity and authenticity, they’ve always been a big part of my life. But for others, like gratitude and self-compassion, they were brand new. Those last two were particularly helpful, in coming to grips with anxiety in general, and social anxiety specifically.

Four of them, are elements, that as long as I maintain some control over my life, they will always be a part of, they include: adventure, freedom, altruism, and big ideas. Now everyone, and particularly Americans, will say they value freedom. But freedom ranks so high on my list, that I’m willing to give up the benefits of say getting a job in order to preserve my freedom. I struggle with the concept of marriage and being a parent, because I value freedom so much. Understanding this, has made it far easier for me to accept that the “traditional” path might not be the right one for me.

The last four are more practical. At the end of the day, you have to get stuff done and this set represents how I want to get stuff done. They include: simplicity, teamwork, ownership, and grit.

And so now, you might ask, so what? What does this have to do with product?

I’ve worked on a lot of different products. I worked with a Science editor on creating a visual map of cellular pathways. I’ve worked on a continuing medical education product. I’ve worked on a search engine, a shopping site, a community platform, a recruiting service. And I was deeply interested in each and every one of them.

But if I’ve learned anything, it is interesting isn’t enough. When things get hard, when things go wrong, if you are merely interested, you lose interest. There’s nothing that motivates you to keep pushing through. It’s not about interesting. It’s about meaningful.

Building products is hard. Building products that people will actually use is really hard. I spent the past few months terrified that I might not find something that interested me enough to take action. Everything seemed exhausting. Nothing seemed quite worth it. I have a whole new appreciation for just how hard it is.

But then I focused on my values. I looked for my meaning. And today, if I ask myself, would I be happy spending my entire life building products that helped people be more grateful, or more curious, or more adventurous, the answer is absolutely yes. I can’t wait to get started.

Have you taken the time to identify what’s meaningful to you? It’s not easy. But I can tell you, it’s absolutely worth it.

Should You Learn To Code?

Posted on by
16

I’m launching a product today. I forgot how exciting it is to launch something that I made, from concept to launch. In this case, I didn’t just define the product, I also wrote a good amount of the code. I haven’t written code in five years, and boy did it feel good to dive back in. I hit a bunch of snags along the way. I’m learning a new language, a new environment, and a lot has changed on the web in five years. But I don’t care. Nothing feels better than being able to say, “I made this.”

I often hear product managers and designers ask, “should I learn to code?” I don’t think you have to write code to be a good product manager or designer today. But I think in the future this might change. I also think that regardless of whether or not you need it, everyone should learn the basics. Here’s why:

It demystifies technology. When you grasp how things work, they stop feeling like magic. Sure magic is fun, but it’s also the unknown. The unknown is scary. So many people are afraid of technology because they don’t know how it works. Looking under the hood can change that. It doesn’t take much to get started and a little bit of knowledge goes a long way. It will change the way you view the world.

It opens your world to new possibilities. When you know how some things work, you start to wonder how other things work. Then you start to wonder why certain things don’t work. And that’s when you start to think like a maker. Why doesn’t it work this way? It could, if it only did this, this, and this. And then before you know it, you are off to making that thing you wanted.

Making things is empowering. There really is nothing more gratifying than being able to look at something and say, “I made that.” When you know you can make things, it’s reassuring. You know that if you absolutely have to, you can always “roll your own.” Most of the time you won’t need to. Other times you might want to, but decide it’s not worth the effort. And occasionally, you’ll get the itch and actually build something. But every time, you’ll be empowered knowing that you could make that if you absolutely needed to.

You gain credibility. This is particularly true if you work in the internet / software industry, but I think it’s true for everyone. If you work with engineers and they know you can write code, suddenly you are in the secret club. If you work with business people who can’t code and you can, suddenly you are viewed as an engineer, but one they can talk to.

It might just be the arithmetic of tomorrow. We grew up with reading, writing, and arithmetic as our elementary school basics. Reading and writing are clearly critical skills. And no, I’m not going to argue that we don’t need arithmetic, but with computers  and calculators, we don’t see “must be able to add, subtract, multiple, and divide” on job descriptions these days. But I suspect it won’t be long before job descriptions ask for basic coding skills, even for non-engineering jobs.

It’s fun. It really is. I know I’m nerdy. But most people I know like it. I went to college in Silicon Valley and we were required to take an engineering class as part of our general requirements. Almost everyone I knew took a programming class of some sort. It was the late 90s, everyone was getting rich. Coding was the cool thing to do. But here’s my point. Everyone liked it, even the English majors. In fact, one English major I know, went on to be an early member of LinkedIn’s team. Yeah, i think he’s glad he learned to code.

So if you ask me, “Should I learn to code?”, my answer will always be yes. If you are a startup founder and you are responsible for the business side, I’d still say learn the basics. If you need a technical cofounder, I’d say stop looking, and start learning. If you are a designer, start with HTML and CSS, then move on to Javascript. Build your own UIs. If you are a product manager, start small, but build a product from beginning to end. It will be slow going, but you’ll learn A LOT about the process. Your engineers will respect you and you’ll have a whole new appreciation for their work, especially for why it’s impossible to give accurate estimates.

So stop reading and get coding. Here are a few resources to get you started:

  • Code Year - Sign up for Code Year to start receiving a new interactive programming lesson every Monday. You’ll be building apps and websites before you know it!
  • Code Academy - Codecademy is the easiest way to learn how to code. It’s interactive, fun, and you can do it with your friends.
  • Khan Academy - Watch. Practice. Learn almost anything for free.
  • Stack Overflow - When you run into problems and you will, ask for help. Or search for your question here. Odds are someone else has had the same problem and has already figured it out.

On that last note, programming can sometimes feel like two steps forward and one step back. It can get frustrating, but don’t give up. Ask for help. With sites like Stack Overflow, everyone has someone they can turn to for help. Don’t try to do it on your own. Learn from those who have been there before.

Now go build something. Then leave a comment and tell me how it went. Or if you already code, share  what it’s done for you. Add your own reasons for why everyone should learn to code.

Build Your Visual Communication Skills

Posted on by
5

As product managers, we have to communicate with everyone: engineers, designers, sales, account managers, marketing, you name it. Our products are usually complex and we are seen as the resident experts. We bounce around clarifying a product spec with engineers one minute to helping to overcome a sales objection the next to working through how a client can use the product to solve a specific problem.

One of the most valuable skills I’ve found in helping to communicate quickly and accurately is visual thinking. How many times have you turned to a white board for clarification? How much easier is to work out a design problem with a pen and paper in hand? Why do we spend so many hours on charts and graphs in our presentations? As the cliche goes, pictures are worth a thousand words, and in many cases, much more.

But far too often, I hear people say they are not creative. They can’t draw. They aren’t artists. But I’m willing to bet each and every one of these people drew, colored, and created as kids. Somewhere along the line, our logical brains take over, and rather than letting us create and explore, we evaluate and judge. In school, we develop our verbal, quantitative, and analytical skills. But rarely do we work on our visual thinking skills. Of course, we aren’t very good at them.

Fortunately, it’s not too hard to change that. You don’t have to be Rembrandt or Picasso, to communicate visually. Nor do you have to go back to school to build the fundamentals. There are a few simple things you can do to help develop your visual skills.

Keep an Idea Log

Carry a sketch book with you. Draw out your ideas as they occur to you throughout the day. You’ll be surprised by how many ideas you have that go nowhere simply because you have no means for capturing them. I had to do this as an undergrad in all of my design classes. I was not an artist. Most of my feedback from the instructors was essentially, “draw more, use fewer words”. But I kept with it. I got better. I never learned to draw per se, but I did learn to capture my ideas with pictures.

Use visual tools like Mind Maps and Concept Maps

For people who really struggle with drawing, this might be an easier place to start. Both help you to think about concepts in relation to space. You are still using words, but you are grouping related concepts spatially, so you’ll still exercise your visual thinking muscle.

Combine images to get your point across.

If drawing really gets in your way, search the web for images. Mix and match to get your point across. Of course, if you are creating a visual to be used beyond your own personal use, abide by copyright laws. But there are plenty of free stock image sites out there.

Basically, do whatever it takes to get started. The more you practice, the more comfortable you will get. You’ll be surprised how effectively you can communicate with crude images.

If you are like me and learn best by reading, here are a few books, you can try:

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures

There is no better book for walking through the benefits and basics of visual thinking. You won’t regret picking this one up.

Understanding Comics: The Invisible Art

A book about comics might seem frivolous, but this book is packed full of visual goodness. I can’t say enough good things about this book. Just trust me on this one.

Presentation Zen: Simple Ideas on Presentation Design and Delivery

If everyone had to read this book, we might actually start looking forward to PowerPoint presentations. This is a great tutorial on the power of images.

Do you have other methods for improving visual communication skills? Or have you found other books to be helpful? If so, please leave a comment.

How To Talk To Your Customers (Despite Henry Ford and Steve Jobs)

Posted on by
18

“If I’d asked customers what they wanted, they would have said a faster horse”
- Henry Ford (supposedly)

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”
Steve Jobs, BusinessWeek, May 25 1998

These oft-quoted quips have managed to stir up a lot of confusion about whether or not we should talk to customers about our products. Most experienced product teams still value customer research, as they should. But for those new to the field, these quotes can be misleading. Even for those who do know that customer research still has merit, it’s hard to know how to do it in a way that actually delivers tangible value. Here are some things to keep in mind.

First, I want to get this out of the way, despite these quotes,

Yes, you should talk to your customers. Every single day.

I really do mean that. Every single day. I know that our days are full. Our lives are busy. I’ve been there. I spent more than two years doing several jobs trying to keep a struggling startup alive. I still talked to our customers every single day. Here’s why. Each day that goes by without talking to your customer is a day that you get further away from building the right thing.

You can’t just do customer research every once in awhile. It’s not a quarterly or even monthly activity. It’s something that you have to build in to every day. It doesn’t have to be a big research project. As a startup CEO, the first thing I did every day was make sure that I had a customer call scheduled for that day. If I didn’t, I picked up the phone and called someone. We also had several users come in each week for ad-hoc usability testing. Out in the world, if I ran across someone who used our product, I used that opportunity to gain a little knowledge. It doesn’t have to be formal, it just has to be always.

The goal is to learn who you are building for, not what to build.

The biggest mistake I see people make is when they do get out and talk to customers, they ask them what they should build. They ask for feature requests. Please don’t do this. You are wasting everyone’s time. What I’m going to say next is going to sound a lot like the above quotes, but there’s an important subtlety here. People have no idea what they want. They don’t know what they would do. They have no idea if they would use a hypothetical product or not. But that doesn’t mean you shouldn’t talk to them.

Talk to them about their problems. Ask them about their day. Observe them. Try to identify whether or not they even have the problem your product is trying to solve. If they do, ask them about that problem. How do they solve it today? Are they satisfied with that solution? How often does the problem occur? Is it a big painful problem? Do other people in their organization have that problem? In what context does the problem occur? It bears repeating: Your goal is to learn about for whom you are building not what you should build.

Don’t ask leading questions.

What’s a leading question? What’s the difference between me asking, “What flavor do you want – strawberry? vanilla? chocolate?” and “What flavor do you want?” It’s a silly example. But a really important distinction. The first puts ideas in your head, it influences your answer. It might even limit what you think is in the realm of possibility. The second allows you to come up with the answer all by yourself.

Let’s look at a more realistic example. Suppose I ask a customer, “Do you have concerns about budget or usage?” Of course, I want to know if the customer does have concerns about budget or usage, but by asking it this way, I’ve done two things. First, if the customer didn’t have concerns about budget or usage, they might now. They are probably thinking to themselves, “should I have concerns about budget or usage?” And more importantly, if they do have other concerns, they might now be overshadowed by these two new concerns that didn’t even exist beforehand, meaning you might never discover them and be given the opportunity to address them.

Listen more than you talk.

Discover these concerns by talking less. Simply ask, “Do you have any concerns?”. Then stop talking. Let your customer respond. Remember, the goal is to learn about your customer, not sell your product. Although, even if you were trying to sell your product, listening more than talking is going to help just as much. Play a game with yourself. See how few words you can say to keep the conversation going.

Ask why or “Tell me more about that”.

You can talk less by relying on my two favorites. Ask why. Or if you don’t want to sound like an obnoxious five-year old, simply say, “Tell me more about that”. Keep score. How often was the response something completely unexpected. It will happen a lot. You’ll uncover countless things that you wouldn’t have otherwise learned if you instead asked a leading questions based on a wrong assumption.

You will hear solutions. Bring it back to problems.

Your customers are inevitably going to talk about solutions. They are going to ask for feature requests. That’s ok. That’s how our brains work. But gently bring them back to the problem. Some good ways to do this include asking, “How would you use that?” or “Tell me about when and why you would use that”. Feature requests are clues to a problem that you haven’t uncovered yet. Dig for the problem. It will be worth it.

To Sum Up

Ford (supposedly) and Jobs weren’t wrong. You can waste a lot of time asking customers the wrong things. But don’t mistake that for never talking to your customers. In fact, if you want to make sure you never fall into the trap of not knowing what you don’t know, do talk to your customers. Just keep the following in mind:

  • Talk to your customers every day.
  • Learn about who you are building for, not what to build.
  • Don’t ask leading questions.
  • Listen more than you talk
  • Ask Why and “Tell me more about that”.
  • You will hear solutions, bring it back to the problem.

Do you have other tips or tricks for uncovering great customer insights? Please share in the comments below.

The “Why” Behind Product Feedback

Posted on by
1

I was talking to a startup founder recently and he was telling me about the feedback he was getting on his recent product launch. To keep things simple, we’ll describe his product as follows: he is creating a platform where buyers can meet with sellers to exchange information about products ahead of a sale.

Talking with buyers he was hearing conflicting feedback. On day one, he heard the buyers say,

“I think the sellers should pay for access to this system.”

But on day two, he heard the same buyers say,

“I think the sellers should not have to pay for access to this system.”

What happened? Did they change their minds? Not necessarily. I asked the founder to tell me more about the context of the two conversations and here’s what we uncovered.

On the first day, the founder was talking to the buyers about how the system would make money. The buyers expressed concerns about budget and concluded that the sellers should pay for the system.

On day one, ”I think the sellers should pay for access to this system. really meant, “I have no money to spend on this product.”

But on day two, instead of talking about budget, they were talking about the reliability of the information being exchanged. In this context, the buyers wanted to make sure that they were only getting accurate information from a trusted source, concluding that if the sellers paid for access, they would no longer be a trusted source.

On day two, ”I think the sellers should not pay for access to this system.” really meant, “I only want access to reliable information from a trusted source.”

Of course, the buyers weren’t this explicit about their needs. Instead, it’s our job as product managers to work to understand the “why” behind the words. When we do, conflicting statements often become constraints within which we can do our work.

Do you have other examples where your customers said one thing but really meant something else?

How to Frame Your Product Vision

Posted on by
6

More often than not, I see product managers frame their product vision as a solution – sometimes even as a solution without a clear problem. In some cases, this happens because the product manager hasn’t clearly identified a suitable problem. But other times the product managers have done their homework and are tackling an important problem, but they are so focused on their solution they begin to mix the two. This can be limiting, particularly when things don’t go as planned.

To illustrate this I’ll continue working with my Caltrain mobile application example from an earlier post. To quickly review, Caltrain is a train service that runs from San Jose to San Francisco. Riders generally fall into one of two categories: daily commuters and occasional riders. The system is not particularly user-friendly and occasional riders often run into problems when trying to pay for parking, buy tickets, and figure out which platform to use.

Using this example, suppose I stated my product vision as follows:

Connect occasional riders with train schedules, ticket buying information and parking information via a mobile app.

This vision statement accurately captures my current view of the situation. But it’s not flexible enough to account for something going wrong. For example, what happens if I learn that occasional riders won’t rely on a mobile app for this situation? Or suppose I discover that train schedules don’t actually help occasional riders? This vision statement is centered around my current solution. If my current solution is wrong, I don’t have much room to explore other options.

In fact, by framing my product vision this way, I’m going to be more likely to solve my usage problems within this context. Rather than questioning whether or not a mobile app is the right approach, I’m more likely to tinker with the app itself to try to grow usage. Context matters. My view of how to fix the usage problems is going to be constrained by how I’ve framed my product vision. If I’m set on delivering a mobile app, that’s the world within which I am going to work, whether it’s the right answer or not.

However, look at what happens if I state my product vision as follows:

Help occasional riders have a seamless Caltrain experience

Rather than focusing on a specific solution, this statement captures the problem I am trying to solve. I might still solve this problem with a mobile app, but if I later learn that occasional riders won’t use a mobile app, I haven’t hit a dead end. I can simply look for a different solution. In this case, the context from which I’m working is the problem that I am trying to solve.

By framing my product vision as a specific problem rather than a specific solution, I have the freedom to explore many different types of solutions. This is important. Odds are your first solution isn’t going to work quite right. But if you have the freedom to explore multiple solutions this won’t matter. Your vision statement gives you the freedom to keep trying rather than hitting a dead end.

Don’t let your product vision limit you. Frame it in the context of an actual problem. It will help you stay focused on the problem itself and you’ll be less attached to specific solutions when they don’t work out.

Great Product Books: Where To Get Started

Posted on by
Reply

I often get asked for book recommendations related to product management. This is a hard question to answer. There are a lot of great books out there. But I think the most important aspect of being a good product manager requires working from the perspective of the whole business. It’s not enough to build a good product. You have to build a good product that customers / consumers not only like but are willing to pay for. It’s the last part that is the hardest to accomplish.

Over time, I’ll write about many of the books that have influenced my perspective on product management. But I want to start with three that I think do a great job of setting the context in which product managers should work.

Four Steps to the Epiphany by Steve Blank

I love this book. I wish I had read it much earlier in my career. This is as close to a step-by-step guide to how to run a startup as I think we’ll ever get. Steve does a great job of breaking up the four stages of building a company from scratch. There are a few things I want to note about this book:

  • It’s easy to say you should get out of the building and talk to customers. Steve shows you how. Often the hardest part is knowing what to ask and Steve includes many great questions to get you started.
  • You might not think the sections on sales and developing a sales roadmap are relevant to you as a product manager, but they are. If nobody buys your product, it means you failed.
  • This is a dense book. I wouldn’t read it all in one sitting. Read the first section on Customer Discovery. If your company hasn’t left that stage yet, don’t read on. Once it’s ready to move on to Customer Validation, read that section next, and so on.

This book will save you countless hours trying to figure it out yourself. Stop what you are doing. Buy it and read it. You can thank me later.

Business Model Generation by Alexander Osterwalder

This is a beautiful book. The Business Model Canvas is a wonderful visual tool that simplifies the complex process of understanding how business models work. It’s well-written. It’s beautifully crafted. As a designer, I love having such a great tool for understanding the nuts and bolts of a business model.

Again, as a product manager, if nobody buys your product, you failed. This book will help you clearly make the connection between your value proposition, your customers, how you’ll reach those customers, and most importantly how you’ll make money from this. I am confidant you will love it.

While I’m a sucker for Kindle books, I recommend picking this one up in print. It’s a beautiful book with fantastic illustrations. Even the Kindle Fire won’t do it justice.

The Lean Startup by Eric Ries

Eric builds off of Steve’s work. This book is getting a lot of buzz of late and I couldn’t be happier. There’s a lot of great material here. My favorite elements include:

  • Focusing on actionable metrics rather than vanity metrics, with great examples.
  • The Five Whys to get to the root cause of a problem.
  • The Minimum Viable Product and a ton of material on hypothesis testing.

You can’t go wrong with any of these books. I’d recommend reading them in the order listed, but if one grabs your interest more than others, start there.

What other books have helped you work from within the context of the whole business?