Hiten Shah on how to avoid common pitfalls of product development

In today’s fast-changing business environment, it’s critical to consistently come up with valid product ideas, scale them and move forward to create the future for your customers. That’s a tough goal, but San Francisco-based entrepreneur Hiten Shah has mastered the art, even with a team that’s distributed all over the world. Working remotely for more than 15 years, Hiten has created several successful SaaS brands (FYI, KISSmetrics, Crazy Egg and others) and wrote the popular book 5 Habits to Building Better Products Faster. We asked Hiten for his insights on building and scaling successful products and how to avoid common mistakes that PMs make.

Anna
Savina

Author

Mathew
Scott

Photographer

What you need to know to build digital products that people want to use:


1

When you build something, ask yourself, ‘Do enough customers really need it?’ It’s also important to talk to customers in an unbiased way. Ask for their opinions instead of their feedback.

2

When it comes to discovering people’s problems, ask for stories. Once you have enough of them you will find the “pattern of pain.”

3

When you are done with research, create the marketing material before coding anything, like the Product Hunt launch assets. That way you’ll choose a future reality for the customer.

In your book, you said that it’s a mistake when startup founders “assume there is one right answer to what customers actually want.” Why do you think this problem is so common?

People build things that they think people want, but when they actually give it to their customers, they don’t want it. Founders are building things that they want, not the customers. When you build something, it’s important to ask, “Do customers really need it? Are there enough of them?”

You never want customers telling you, “I need this.” Instead, you want customers to say, “This is my most important problem right now.” You have to figure out what customers really care about. Do they need it solved so badly that it’s worth your time? The most innovative solutions come from identifying people’s core problems.

If you have an existing product, don’t just add new features. Find out what people’s problems are, now that they’re using your product. You might realize that you don’t need to add a new feature; you need to make improvements.

If you don’t have a product yet, then it’s really important to talk to customers in an unbiased way. Tip #1: ask for people’s opinions instead of their help or feedback. Nobody wants to give another person feedback, but everyone is willing to share their opinion. That’s a key nuance that people struggle with.

When it comes to discovering people’s problems, one thing that works well is asking for stories. “Tell me about a time when you had trouble communicating with your remote team.” This is key information I would ask for if I were doing research on RealtimeBoard.

Once I hear enough stories, I will find what I call the “pattern of pain (PoP).” It’s my key for customer development. If the people you’re talking to are of a similar demographic, you’ll find a pattern after a few dozen interviews.

Profile


Hiten Shah

Hiten Shah is a co-founder of several SaaS companies including FYI, Crazy Egg, Product Habits and KISSmetrics. Hiten has an email newsletter called The Weekly Habit, where he shares the best links of the week for anyone interested in Product. He is also a co-host of the podcast The Startup Chat. You can follow Hiten on Twitter or LinkedIn.

Nobody wants to give another person feedback, but everyone is willing to share their opinion

5 Habits to Building Better Products Faster

Can you give me an example of going from a problem that you wanted solved to a problem that is important for the market and for your audience?

We built a product that failed called Draftsend. It was essentially a SlideShare or DocSend competitor. We wanted to help people communicate better by adding voice to documents. We did some research and found some sales and marketing use cases.

We thought people had a problem communicating online because it’s just text with no audio. While we were building the product, we discovered a much bigger problem: when we asked people for their number-one challenge with documents, they said, “I have a hard time finding and organizing my documents.” We were really excited about the document market; we thought it was a big space. Our findings led to us to build another company, FYI to solve the biggest problem people have with documents: Finding them.

Draftsend failed because we didn’t find out what people’s real problem was before we built the product. Now, when we build something, we really focus on being sure that what we are building solves the most painful problem in the market.

Why do you think a lot of companies don’t do enough customer research?

Doing customer research is hard because you have to set up time to talk to people. You have to be willing to hear what they have to say, even if it invalidates whatever you’re thinking. It’s super difficult unless you realize how much harder it is if you don’t do it. Most people understand that. Humans don’t like being wrong. When we’re wrong, we want to be right, so we ask biased questions.

To do product development, you have to learn skills that we were never taught growing up. Most of us weren’t taught to react to feedback in a positive way. I believe that learning to take feedback without reacting negatively is the breakfast, lunch and dinner of champions.

Humans don’t like being wrong. When we’re wrong, we want to be right, so we ask biased questions

What are some of your favorite tactics that help you avoid these pitfalls of customer research?

I use the mute button on whatever tool I’m using to do the interview. I’ll ask a question and then be as silent as I possibly can. My goal is to listen patiently and only talk about 10 or 20% of the time when I’m doing an interview. Silence is your best friend in these customer interviews. When the customer is silent, they’re thinking about the question, and you shouldn’t answer it for them.

I also try to get stories out of people. If they say, “I have this big problem, and I don’t think your product solves it,” I resist the urge to respond to their critique during the interview. I take notes and might respond to them later in an email, but I make sure not to ruin their train of thought. If we can solve a problem, but the customer thinks we can’t, I want to know why they think that. That’s when I’m going to learn where we’re doing something wrong.

Are there any common mistakes people make when they do customer research?

One common mistake is not digging deep enough. When customers say they have a problem, you might not ask why and move too quickly to the next question. When you hear something interesting, make sure you understand why the customer said it.

Another tactic I use in interviews is repeating back what I think the customer said. They will often correct me or give me more information. You’re really just trying to get them to talk as much as possible. People don’t like talking about their problems, so you have to use a bunch of strategies to get them to open up.

I’m interested in this idea pioneered by Amazon of working backwards instead of towards a roadmap. Can you explain this bit?

I really believe in this methodology. At Amazon, they choose a future reality for the customer by doing a ton of research. Then they write up a document like a press release about the launch of the product. They’re really trying to make sure they build the right thing.

My adaptation of that is doing a ton of customer research, figuring out the problem and then writing a launch blog post instead of a press release. At FYI, we also create the Product Hunt launch material for the feature before we start coding it. We create all the assets and write fake reviews. The whole idea of working backwards is to make sure that you nail the problem and your solution before you write any code. This way the team has something specific to build towards that always aligns with the customer need.

Transformation through design thinking: inside BCG Digital Ventures, Europe’s leading startup builde


One of the key ways to avoid product failure is to understand your customer’s expectations

“Lean UX” author Jeff Gothelf on how to deal with challenges of Agile transformation


How does working backwards compare to building a roadmap?

Roadmaps are useful for rallying your team in an organized way toward creating a solution to customer problems. The main pitfall of a roadmap occurs when the solution you create doesn’t matter to customers. Think of working backwards as a process that helps make sure your roadmap is always focused on building the absolute best, most meaningful product for your customers. A product your customers will love.

How often do you tweak or iterate on your roadmap?

It depends on the stage. At the super-early stage, your roadmap will probably change every week as you look for an early sign of product/market fit. Once you hit some initial product/market fit or traction, you go into a monthly and eventually quarterly cycle of roadmapping.

As I’ve scaled businesses and seen other businesses run, I’ve started mapping out three to six months ahead based on customer research. As a rule of thumb, once you get traction, you should be doing enough customer research upfront to construct your roadmap for three to six months or more.

How do you gain product momentum? What does it mean to you, and why is it important?

Momentum is really important and has everything to do with customers. They need to see that you’re willing to make improvements that make their lives and your product better. The more often they see that, the more they trust you and want to give you their business. That’s why it’s so critical to solve the right problems for customers and make sure the team is aligned on them.

Communicating with the team about the research is really important. At FYI, we spend a lot of time creating documents that help the whole team understand the problems we’re trying to solve for our customers and why.

When we were launching our desktop app for FYI, we learned that people want the files on their hard drive to be findable using FYI. We were not going to launch a desktop app unless it did that. It’s really easy to build a desktop app with some of the technology out there — Electron framework, specifically — but this one feature requires a lot of effort. We made sure that the engineering team knew how important it was for our product to be able to get the documents on your desktop into FYI. When you communicate with your team, you create momentum to do something really hard; if it’s important for the customer, it’s important for your product.

I also like to maintain momentum with deadlines. We have three different releases when we launch a product. There is an internal release just for our team. There’s another release for early access customers and then a third and final release to our whole customer base and sometimes the outside world, on Product Hunt or to the press. These three releases create momentum and help us learn. We make sure we ship on time by communicating with the engineering team as much and as early as possible and making sure that everyone is aligned on the most important aspects of each release.

Does momentum have something to do with the status of the market, competitors or some other external factor?

If we focus too much on external factors, our momentum is based on other people’s momentum. Instead, we focus on the customer.

If the customer says that another company is doing a better job than us, then we try to understand what we could be doing better. But we don’t spend a lot of time comparing ourselves to what competitors are doing. It always goes back to the customer.

Use an online whiteboard to build and scale products in distributed teams.

Try RealtimeBoard free,

no strings attached


Read also

Product Management Today