Interesting vs. Meaningful

Posted on by
8

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
13

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.
  • Stach 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
15

“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?

What Product Assumptions Are You Making?

Posted on by
4

When a team sets out to develop a product, they generate a series of hypotheses. In my experience, good teams are explicit about these hypotheses and test them before they invest too much time into a particular product plan. However, more often than not, I see that development teams are not even aware that these hypotheses exist, instead building their products as if they were fact. The problem with this approach is that rarely does a team get all, if any, of these hypotheses right from the get-go. If they don’t first test them, they run the risk of building a product that nobody wants. Let’s take a look at an example to illustrate how this works.

Explicitly Enumerating Product Assumptions as Hypotheses

I have an idea for a Caltrain mobile app. Caltrain is the local train that runs from San Jose to San Francisco. Riders include daily commuters and occasional train riders. As a daily commuter, I witness a number of problems experienced by occasional riders. They don’t know how to buy tickets, they don’t know how to pay for parking, they don’t know which platform to stand on. They don’t know how to tell what stop they are at or when and where to get off the train.

I suspect that if Caltrain tackled some of these problems, they might convert more of these occasional riders into daily commuters, growing their ridership. I’ve often considered building a Caltrain mobile app that addresses some of these usability problems.

The app would walk the occasional train rider through each step of the process of riding the train, starting with where to park, how to buy a ticket, updates on when the next train is coming, updates on where you currently are relative to where you want to get off the train. My goal would be to make it as easy as possible to ride the train.

I ride the train every day. I know how to do all of these things. I’ve observed these problems first hand for years. Should I just get started and build the app? How do I know that occasional riders will want it?

Let’s take a look at some of my assumptions or hypotheses underlying my app idea.

  • H1: Occasional train riders will download a Caltrain mobile app before they ride the train.
  • H2: The problems that occasional train riders experience are big enough that they will remember to use the app they downloaded earlier to help solve their problems.
  • H3: The desire to ride the train is great enough that if occasional train riders had help they would ride the train more frequently.

It’s quite possible that occasional train riders don’t anticipate having problems. If they did, they would probably choose to drive rather than take the train. So H1 could be a big hurdle.

H2 may not be as big of a hurdle. It’s possible that if I did download the app and I run into a problem, the problem itself may act as a trigger to remind me I have the app. But that still needs to be tested. It might be easier for me to just ask somebody nearby. Or I might just give up, something I see people do daily.

With H3, if my goal with the app is to help grow Caltrain ridership, then I am assuming that the reason people don’t ride the train more often is because it’s hard. This might be part of the problem. But there are a number of other reasons why occasional riders might not take the train more often – the big one being that it is often slower than driving. Even if people had all the help they needed, they might still choose to drive over taking the train because they simply want to get to their destination sooner.

Testing Each Hypothesis

Before I decide whether or not it’s worth it to build this app, I want to test each of these three hypotheses. But how do I do that?

H1 is fairly easy to test. It requires that riders take action on their phones or computers before they ride the train. Using the Google keyword tool, I can easily find out how many people search for keywords like Caltrain schedule, Caltrain tickets, Caltrain parking, and other phrases I identify as related to some of the problems I want to tackle. If the numbers are high enough, it will validate that people do in fact seek out this type of information.

But that’s only part of the story. I also want to validate that the riders seeking this information would download a mobile app to solve their problems. How do I do this without actually building a mobile app?

Again, Google can help. I can build a simple splash page for my mobile app – a webpage that talks about the features and benefits of the app and ask visitors to download it. To get visitors to this page, I can buy Google Ads for the keywords I uncovered in my first test. But wait, there’s no app to download? That’s okay. I’m just testing whether or not visitors will click on the “Download” button. If they do, I can always apologize that the app is not yet ready and let them sign up to be notified when it is. This does two things, 1) it validates that people will take action to download an app and 2) it lets me build up a potential user list before I start building.

H2 might be a little bit harder to test. But here’s where some creativity can help. How do I test whether or not someone will remember they have an app when they don’t in fact have an app. I can fake it, just like I did for my H1 test. Here are a couple of ideas:

  • I can ask friends who are occasional train riders to call me when they run into any of these problems. Do they remember to call me? Do they figure it out on their own? Do they just give up?
  • Better yet, for the folks who clicked on my “Download” button when testing H1, I can ask them to bookmark a page that acts like an app, so it’s available on their phone. The page could be as simple as an FAQ, or could allow the user to enter their own questions that I directly answer. Either of these would be simpler to manage in the short-run than the full app and either gives me the data I need to know whether or not riders will remember to use the app.

H3 is even tougher yet. But still not impossible. I can ask my early users (again, I have users even though I don’t yet have an app), to tell me how often they ride the train. After they’ve accessed the fake app a certain number of times, I can ask them again how often they ride the train. If their ridership goes up over time, I’ve validated my hypothesis.

I already know what’s going through your head. If I’m solving the problem with an FAQ or by answering one-off questions, why would I build the app at all? That’s exactly the point, I wouldn’t necessarily have to. I would have all the data I need to know exactly how much product to build to solve the problem I set out to tackle. If I’m answering one-off questions, I probably still want to build a product that automates this. If a FAQ is getting the job done, I might learn my problem was much easier to solve than I originally thought. It’s not about my original product vision, it’s about solving a problem, meeting a market need.

It’s An Iterative Process

Even if I can prove all three of these hypotheses and I decide to build the app, I’m not done testing hypotheses. Each step along the way, as I build out the app, I’m going to keep layering more hypotheses onto the ones I’ve already tested. Product development is an iterative process. But if I keep testing each assumption, I’m very unlikely to build too much of a product that nobody wants.

Next Steps

In a future post, I’ll explore how to get better at surfacing assumptions and turning them into explicit hypotheses. In the meantime, what do you do to make sure you aren’t building products on too many untested assumptions?

Turning Big Ideas Into Great Products

Posted on by
Reply

I love seeing big ideas turn into great products. In this talk, Jack Dorsey talks about the big idea that eventually led to Twitter and his new big idea behind Square. Few people have the ability to go from big idea to successful product like Jack does. Even for ideas with narrower scope, much can get lost in the implementation. But why is this?

In talking with founders, investors, product folks, designers, and engineers, here in Silicon Valley, I’m starting to realize that product management is still grossly under-developed. At many startups, the function, if it exists at all, is nothing more than translating feedback into feature lists, prioritizing that list, and calling it a product roadmap.

How many startups have defined a product strategy that clearly outlines what they might build and more importantly what they won’t build? Most of us are familiar with contextual inquiry, needs analysis, usability testing, A/B testing, among other tools, but how often are we using them?  We know these tools are valuable. Why don’t we integrate them into our practice more often?

In some cases, the problem might be lack of knowledge. The 22 year-old, new college grad, who just raised a seed round, might not know the value of usability testing or contextual inquiry. Likely, he had a big idea, and sold a set of investors on that idea. That’s a great accomplishment. But it’s only the beginning.

For others, they might know about these tools, but lack the know-how to use them. I might know that I should do market-research, but if I don’t know how to construct a survey without asking leading questions, I’m probably not going to get very good data. In fact, I’m going to get data that merely confirms my assumptions.

And yet for others, they may have both the knowledge and the know-how, and yet still fall short in practice. It’s this last case that is most interesting to me. I’ve been in this situation myself many times. I’ll be the first to say I did not test every design. I have ignored valuable user feedback that turned out to be significant down the road. I have stubbornly clung to my product vision in the face of a mountain of data telling me I’m wrong.

Why does this happen? I suspect psychology can tell us a lot. I’m sure cognitive biases are at play. I know that the time pressure of most startup environments is a big factor. When there’s pressure to ship, it feels like there just isn’t time to use these tools. But I suspect by cutting them out, we are taking more iterations than we need to to get to a product that our customers want and can use.

My questions are as follows:

  • How can we, as product managers, do a better job of leveraging the tools of our trade?
  • How do we refine our methods so that we adopt them more often in practice?
  • Can we develop new methods that help us overcome our cognitive biases so that when we do leverage these tools, we are more likely to integrate what we learn?

Through my consulting practice, drawing from both academic and business literature, and in conversation with others, I’m looking forward to exploring these questions. I plan to blog about the experience and suspect topics will include:

  • Product Strategy
    • linking product vision to company mission
    • developing guiding principles / values
    • understanding business model options
    • accounting for distribution
  • Product Discovery
    • uncovering customer needs
    • understanding context
    • conducting ethnographic research
    • conducting survey research
    • working with sales and client services
  • Idea Generation
    • setting the scope
    • asking the right questions
  • Working with Engineers
    • writing requirements
    • setting project schedules
    • working with engineering estimates
  • Prototyping
    • building prototypes
    • validating prototypes
    • starting with the minimum viable product
    • defining iterations
  • Usability Testing
    • conducting studies
    • communicating the results
    • applying what you learn
  • What Users Really Do
    • learning from A/B Testing
    • understanding traffic analysis
  • Product Performance / Meaningful Metrics

Again, whether you lack the knowledge, the know-how, or the practice, my goal is to focus on how we can evolve the function of product management so that more big ideas turn into great products. I’m really excited. I hope you’ll join me.