Sprinting to product-market fit

I’ve spent a decade building products as a YC founder, Product Manager, and side project hacker. Some were used by millions of people, some were small successes, and some completely flopped.

For the first time in my career, I’m full-time as a solo, bootstrapped founder.

With limited financial runway, I need to quickly build a product that users love and pay for.

In this post, I walk through how I’m building an MVP that’s valuable, not just viable.

Inspired by Google’s Design Sprint

The Design Sprint is a five-day process for solving problems and testing new ideas, invented by Jake Knapp at Google.

I adapted it to my situation - a bootstrapped founder going from idea to MVP.

Finding a problem worth solving

Before I brainstormed solutions, I needed to find a problem that was worth solving. That process looked like this:

Step One - Start with a problem, not a solution

People buy products to solve problems. In Step One, I chose a problem to solve:

Step Two - Choose a niche

Niching down makes everything easier in the early days.

In Step Two, I niched down from remote worker to remote product or engineering leader in tech:

Step Three - Validate the problem

In Step Three, I talked to my niche and learned that they’re investing quite a bit of time and money into solving my problem.

I wanted to build up a waitlist to get a stronger signal. So I came up with a name (HelloHailey) and built a landing page that funneled visitors into a waitlist survey .

So far, I’ve collected 62 waitlist signups in three weeks 😁

Step Four - Figure out distribution

When it comes to launching a software product, distribution is at least half the battle.

In Step 4A, I identified potential distribution channels and strategies for attracting the right eyeballs.

In Step 4B, I learned how to convert those eyeballs into paying users with a “Land and Expand” growth strategy.

...which brings me to today. I’m confident I’ve found a problem worth solving for users I know how to reach. 

It’s time to design a solution.

Designing a Minimum VALUABLE Product

You’ve probably heard of the term MVP, or Minimum Viable Product. It’s the first version of a product designed to test out a new idea.

My goal is to build a product that’s not only viable, but valuable.

I won’t get there by diving straight into code. I’m going to follow a defined, step-by-step process that will help me:

1. Build a better solution (obviously goal #1!).

2. Answer the most important questions first.

3. Create logical checkpoints from which to iterate.

Step One - Vision

As an optimistic, excitable startup founder, I see shiny objects everywhere. A vision will be my north star - helping me decide which ones to chase and which ones to ignore.

Here’s mine:

Life is short. And work takes up most of it. I’m a firm believer that it can and should be both fun and fulfilling.

Step Two - Inspiration

All products copy those that came before them.

Some copy at the surface level (the “what”)

Nobody likes to see entire features being blatantly copied.

But when it comes to log-in screens, buttons, or navbars, I’m all about it. Following established UI patterns makes products easier to use.

Some copy underlying product motivations (the “why”)

Buzzfeed (quizzes) and Spotify (“Wrapped” annual summaries) both generate content that gets users to spread their brands on social media.

Linkedin and Facebook both give users prompts that get them to create more content.

I’ll be copying too!

I obviously want to be inspired by products that attempt to solve my problem.

But I also want to learn from entirely different products - these get me thinking outside the box.

Enter the inspiration wall

I curated screenshots from twenty different products, adding unpolished, stream-of-consciousness style comments:

1. “X has an amazing first-time user experience.”

2. “I love how Y uses gamification to drive engagement.”

3. “I love this feature in product Z. How might I adapt it for HelloHailey?”

See the complete inspiration wall here

Step Three - How might I...?

I turn user problems and product inspiration into opportunities using “How might I…” questions.

I started by writing down as many as I could think of. Then I trimmed it down to five or six; then my top three.

Figuring out what to build became an exercise in answering these three questions:

Step Four - Solution brainstorming

It’s time to put it all together.

I’m going to brainstorm solutions that:

1. Answer my “How might I…” questions...

2. in ways that are inspired by other products...

3. and are true to my vision.

I spent a couple hours putting pen to paper - low-fidelity designs, rough specs, high-level user flow charts, etc. - anything that could describe a solution.

Here’s my top three:

“Guess Who” is a question and answer game in Slack where teammates guess who said what.

The basic flow looks like this:

1. Team lead creates a new channel in Slack and invites the Hailey Slack bot.

2. When team members join, Hailey DM’s them with a series of icebreaker-style questions.

3. Hailey feeds random answers into the team channel throughout the day - without sharing who said them.

4. Team members guess the person that said each response.

5. Hailey shares the answer after all time zones have had a chance to respond.

6. Hailey awards points for correct responses and maintains a leader board.

Hailey is the world’s greatest (Slack) party host. A team lead adds her to a Slack channel, invites teammates, and the party is on.

She sparks spontaneous conversation and unscheduled team bonding that doesn’t feel forced. Her content could include:

1. Introductions - messages that mention a specific user (using @username) after they join.

2. Hot takes - get the room’s opinion on some “controversial” topics - ex. “Is a hot dog a sandwich?”

3. Challenges - ex. Fitness Friday, Taco Tuesday, or “Ice bucket challenge” - anything that asks users do something.

4. Icebreakers - This term can get a bad rap, but I think it’s possible to come up with some that really get people engaged.

5. “Fresh content” - To make content feel unique and “fresh”, I’ll do some manual curation on a weekly basis (or integrate with data feeds):

   1. Food - recipes and video clips (like this Tasty video)

   2. Travel - photos and videos to get people to weigh in on their favorite travel spots.

   3. News - breaking news, new product releases, etc.

Themed Rooms are virtual spaces full of coworkers that share similar interests.

A user can create a “room” by choosing from a set of pre-selected themes, like basketball, books, running, or food.

A “room” could be a channel inside Slack or Microsoft Teams - places where users already spend their time.

Hailey contributes theme-specific content to each room via:

1. A pre-generated list of topic-specific prompts, randomly sent into the room (ex. for the “running” room - “What’s your running goal this week?”).

2. Data streams for more dynamic content: scores and highlights in the basketball channel, tips and upcoming races in the running channel, and recipes and Instagram pictures in the food channel.

🥳 Ain’t no party like a Slack party

I’m going to build the Slack Party Room concept.

Here’s why:

1. Low complexity - I think I can build out a working prototype in 2-4 weeks. I can easily reduce scope by supporting fewer prompt types.

2. High engagement (Hopefully...🤞) - This is my best answer so far to “How might I make conversation prompts that people actually enjoy talking about?”.

3. Always on - Too much of today’s remote socialization feels forced, only happening during pre-scheduled, synchronous video calls. I want to replicate that in-office experience of bumping into coworkers at the coffee machine and just chatting about nothing in general.

❓ Will it work for widely distributed teams?

My hypothesis is that users in non-overlapping time zones will engage in each other’s conversations asynchronously. If they don’t, I’ll have to either (1) iterate on my product or (2) iterate on my niche.

Step Five - Core hypothesis

The Slack Party Room concept relies on one critical hypothesis:

If this is proven wrong, the product will probably fail.

The goal of my MVP will be to measurably prove or disprove this core hypothesis.

Step Six - Write an MVP spec

With a core hypothesis in hand, it’s time to outline the requirements for an MVP that can test it.

I scoped down my ideas from the brainstorm into something I can build in just a few weeks.

Here’s a high level summary:

Hailey is the world’s greatest (Slack) party host.

Hailey creates a fun, lively atmosphere that gets teammates talking throughout the workday. She does this by sending messages of two different types:

“Introduction” messages

These mention a specific user, encouraging them to respond. These will be less about learning facts about teammates, and more about fun, icebreaker-style questions that offer a glimpse into their personalities.

Introductions help make every user feel comfortable engaging in the channel.

“Generic” messages

Just plain text. They could be anything at all. I want maximum flexibility to be able to learn what types of content users like; then create more of it on the backend.

“Generic” says more about the underlying data structure than the message content.

Here’s the core user flow:

1. User installs the HelloHailey app through the Slack app directory.

2. User creates a new channel in Slack.

3. User adds their teammates to the channel.

4. User adds the Hailey bot to the channel.

5. Hailey introduces herself and pins her message to the channel.

6. Hailey sends her first “Introduction” message, tagging the team member that installed her.

7. Every day (spaced throughout the day), Hailey (1) sends an “Introduction” message for a new teammate and (2) sends two “Generic” messages designed to get people talking.

Check out the full spec here

Am I crazy?

What do you think of my process? How can I improve my MVP? I’d love to get more feedback before I start building.

Let me know on my Twitter thread:

Tim Jones @AnotherTimJones

I spent the first month of my MVP Sprint finding and validating a problem. Over the last 2 weeks, I designed a solution for that problem, starting with an MVP. I followed a six step process to design an MVP that's *valuable*, not just "viable" 👇👇

2:08 PM ∙ Dec 7, 2020

It’s (finally) time to build!

Spec in hand, it’s time to fire up the text editor (Vim, of course 🤓) and get to work.

I’m setting a launch deadline of January 15.

I don’t want to spend any more than a month building it (but also want to enjoy some family time over the holidays).

I’ll give an update in two weeks with how it’s going (maybe even an early demo! 😁).

Want to follow along? Subscribe here to get the update in your inbox:

Send me next week's update

Icons made by Freepik, Icongeek26, and Pixel perfect from Flaticon