Skip to content
Chris Prinz
About Me
Writing
Building
Reading
More
Share
Explore
Writing

icon picker
Product development for startups

Building a product that users love requires focused creativity, technical excellence, and a level of customer obsession most people would see as unhealthy. Whether your customer is the Fortune 10 executive or the urban millennial, you have to understand them deeply to create something that they truly want. The ideas below were inspired by my experience at a YCombinator company that was struggling to find product-market fit. The company had adopted a culture of experimentation, but the experiments were failing and the customers were churning.

We were talking to customers, but we weren’t really listening.


Does your company think about making large pivots often?
Do you have trouble aligning your team around a single product vision?
Do you feel like you haven’t yet found a burning need for your product?

This guide will help you focus on creating hypotheses about what your users want and quickly validating them as you iterate towards something that your customers truly want. It’s structured to be as actionable as possible while remaining flexibly generic. All companies are different, and some of the action items below may need to be creatively adapted to your business or project. However, the higher level fundamentals should hold true for any product; crafting your story and building it into reality.
⁠
image.png
⁠
⁠

Crafting your story

If you’re creating a product, it means you’ve found a problem worth devoting thousands of hours to solving. You’ve dedicated years of your life to charting a map to an island far away, slaying the dragon that guards an enchanted cave, and walking away with a mountain of gold and hopefully an IPO. Like all stories, product development phases between two modes: conflict and resolution.

Tell me where it hurts

Unless you’re working on deep technology that requires years of novel research, you’re probably working on a problem that thousands of people have attempted to solve already. If you do research and literally nothing exists to solve this problem, then you may want to rethink how big of a problem it actually is. Your product should be unique, but certainly not alone.

Identifying conflict is about nailing down your value proposition and defining how to deliver on it in a way that will be satisfying and delightful.


Using your product should feel like removing a pebble from your shoe on a long hike. It should feel like 5 Gum. This section will cover how to identify the villain that’s been tormenting your customers using three tools:
The user feedback loop
Experiment driven development
Customer-first company culture

For the love of God, not another survey!

People often default to creating a survey when they want feedback. Surveys are good when you want to gather feedback around something that you’ve already built, where the user experience is easily quantifiable into a bad-good vector. The issue with surveys is that it makes the product development process feature-centric, not user-centric. You start with a feature or an idea, and to validate it, you put together a survey: From 1–10, is this a problem in your life? From 1–10 would this feature help you solve it? What else can we build to help you solve this? You already know what you want to build, and you didn’t ask for validation, you basically demanded it.
To make your product development user-centric, you need to create a user-feedback loop that enables discovery as well as validation. Superhuman, branded as the fastest email experience to have ever existed, did this impeccably. What they did was widely considered controversial but it now the gold standard: they manually on-boarded every user. This had two core advantages. The first was that they were able to ensure that every user had the best experience possible, turning them into email productivity zealots. The manual on-boarding process showed users how to be power-users within their app so that they could adapt their currently ingrained email workflow to the new Superhuman enlightened way of working. Because manual on-boarding can’t accommodate scaling quickly, they maintain a waitlist that is more than 180,000 people long as of this date. Jumping ahead in line requires that you refer other people, driving viral growth. The biggest advantage is that users have to declare why they want Superhuman and the features necessary to make them love it. If Superhuman can’t deliver on their expectations, they will explicitly tell the user that they’re just not ready for them yet. The second core advantage was that they were constantly gathering user feedback and building user empathy across the whole company. They had a steady stream of opportunities to understand what pains users had in their current email workflow, and anyone in the Superhuman team could conduct that on-boarding session and learn about them. This is immensely powerful, but not for the reasons you’d expect. Of course talking to users is important, but it’s also difficult and time-consuming. If you have to set up a bunch of user interviews whenever you wanted to validate a new idea or learn more about customers, you’d be waiting weeks between product iterations. This is why people default to surveys; they’re easy and you typically hear what you want to hear. The reason manual on-boarding is such a valuable feedback engine is that user interviews are coupled directly to user-acquisition. By gaining more users, you’re enabling yourself to conduct more interviews and accumulate more feedback.

Try this

Find ways to tie user interviews and check-in calls to revenue driving activities

⁠
image.png
⁠
⁠

Art and Science

Doesn’t it feel good to be right? When you’ve had an idea and you’re able to prove to yourself and others that it was the right thing to do, it’s emboldening. Surprisingly, as much as people enjoy being right, they don’t measure their successes very often. To understand if a feature is achieving the desired result, you have to become experiment driven. When I was in third grade, I competed in the elementary school science fair. I had a clip-on Spongebob tie, and I would talk your ear off about circuits and the conductors and insulators that allowed electrons to flow freely or be held at bay. My cardboard tri-fold had three sections: Hypothesis, Process, and Conclusion. Unfortunately, I was about four hundred years too late with my discovery of electricity, but I did retain something valuable that I still use in product development: the scientific method.

Applying the scientific method to your product will force you to define what success looks like with every feature you build and measure it over time.


For every feature, you define a hypothesis, success metrics, and results. The hypothesis is based entirely on your user-interviews. By this point, you’ve identified the most important, burning problem you need to craft a solution for. Writing a hypothesis around this will remind you why you built this feature when you look back at your metrics. For example, if you’re building a review feature in a dog-walking marketplace app, the hypothesis could be something like this:
“By adding reviews, we enable users to feel more comfortable with dog walkers and book more walks with a variety of people”
How does this manifest itself in your metrics? The average number of walks-per-walker-per-month should rise due to the increase in trust and the variance (how much the number of walks per month varies per walker) should decrease as walks are being more equally distributed among walkers. These would be your success-metrics, or how you know that the experiment worked. Conveniently, this doesn’t require that you implement an analytics or tracking solution in your app. You can run this experiment exclusively with the data in your database. As you measure these metrics over time, you’ll begin to draw a conclusion on whether or not the experiment was successful. From there, you can decide to continue to iterate on the feature or pull it out entirely.
This approach enables teams to move faster. Many teams assume that they should just track everything in case they need it later. Unless you’re rapidly scaling and have a large and growing user-base, that assumption will only slow you down. Experiment driven development allows you to have focused and productive ideation sessions around what to build next and understand quickly whether or not it worked.

Try this

Define hypotheses and success metrics for your next feature idea. If you decide to build it, measure the results and share them with your team

There is no “I” in Product

Your entire team should be building customer empathy. Sometimes, dog-fooding (the practice of using your own product, or eating your own dog food) will accomplish this, but in the end, you’re not building a product for your company. You’re building it for your users. At Slack and other successful companies, every employee spends a few days a year helping customers resolve their issues. As employees talk to customers, they’re reminded that behind the pixels they push is a product, and behind that is a human. They’re reminded that this human has desires, fears, insecurities, and values. And they take this into their work as they craft meaningful experiences whether it’s in design, sales, or engineering. An “Everyone does support” mentality is a huge cultural initiative that’s actually easy to start. Once you’ve created your user feedback loop that’s generating calls with users every day or week, use a scheduling tool like Calendly to put everyone in a round robin to host these calls. Be mindful of people’s schedules. If your team starts having fragmented, unproductive days, they’ll find it very easy to justify avoiding user contact. In the long run, building a user-centric culture depends on everyone in the company actually talking to users, so it’s important that you set up your team to do this successfully.

Try this

Make sure that every person on your team talks to at least one customer or potential a month. Find ways to make this happen and hold people accountable.

Iteration, iteration, iteration

Unfortunately, you’ll never be able to create a panacea for your user’s problems. Rogue behaviors will emerge from your solution, and you’ll have to go back to the drawing board. However, by creating a user feedback loop that runs itself, empowering your team to be truly user centric, and rigorously defining and measuring success, you’ll consistently deliver delightful experiences to your users.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.