You have enough features: how to stop obsessing and launch your startup

Originally published on http://www.appsterhq.com

The startup world is obsessed with ideas.

Big ideas.

Lightning bulb ideas.

Billion-dollar ideas and some really, really bad ideas.

But, instead of talking about your app or digital product idea, let’s re-frame it as a hypothesis — that tentative, testable answer to a question and the basis of the scientific method you learned back in grade school.

Anyone who’s obsessed with apps (you’re in a safe space here) will also be familiar with the concept of a Minimum Viable Product, or MVP.

It’s the most basic version of your app that could possibly go to market.

An MVP is supposed to be lean, but in my experience at Appster, many founders start packing their fledgling app full of features.

They keep cramming until they have an overstuffed, maximum viable product that sits, bloated and lonely in the marketplace.

To avoid this fate, think of your initial app as a hypothesis. It’s an educated guess about what people need or want, and how they’ll use your product in their day-to-day lives.

What are you trying to validate?

Imagine you’re developing an app that enables doctors and patients to share medical records and personalized care instructions.

The core question you’re trying to validate has nothing to do with features. Instead, you need to know:

  • Do doctors have enough time and/or interest to participate in a new system?
  • Are patients interested in having their records or care instructions on a mobile device?

Secondary questions could include:

  • Are medical clinics or hospitals open to this new system?
  • Are there any conflicts with current digital applications or practices?
  • Are there legal or compliance issues? Privacy concerns and barriers?

Go low-tech and talk to potential users

Testing your hypothesis (product idea) can and should begin offline.

Talk to real people, explain your concept, and ask specific questions.

Imagine how Airbnb founders Brian, Nathan and Joe could have validated their accommodation-sharing concept by approaching guests who were checking in at hotels:

“Hey — I have a spare room. If you give me $75, you can come home with me now.”

There would have been some strange looks, for sure. A few guests might have even called security. But, it would be immediately clear that:

A — People do want new and different accommodation options
B — The creep factor is real, and it’s a major hurdle

Our testers would have known that verified profiles, confirmed reviews and secure bookings were must-haves.

People would need to build trust and get to know each other a little before keys were exchanged. After a few awkward conversations, these founders would better understand their users’ most pressing needs and concerns.

Even as you dip your toe into real technology, you can begin to validate your product hypothesis without building a functioning app.

Take Resistbot, which turns text messages into formal letters that are faxed to U.S. government officials. I don’t know if the founders plan to turn this service into a full mobile app, but with over 13,000 Twitter followers and significant media coverage just six months after its February 2017 launch, people are certainly paying attention.

Whatever questions you need to validate, you can start now.

  • Talk to your potential users and different customer types.
  • Look for barriers, questions and natural objections.
  • Find the sticking points and think about how the product will overcome those issues.

We don’t always know what we want

As you work to validate your concept offline, before any coding takes place, keep in mind that people often resist change.

Just 10 years ago, getting into a stranger’s car, finding love on your phone, or booking a spare room halfway around the world were ludicrous ideas.

The core issues, however, were real.

People were ready and willing for more convenient transportation, dating and travel solutions; they just didn’t know what was possible.

Validating your hypothesis also means figuring out what makes your product unique — apart from design, interaction, price, features or branding.

— What will you do better than the competition?
 — What will you offer that’s not available now?

How you answer these two questions will help to determine what goes into your MVP and what can stay on the list for later.

Return to them again and again. You can and will veer off track, but these simple questions can pull you back into orbit.

I’m overwhelmed. How do I choose what to include?

Consider the 80/20 rule.

If users can select brown, black, red or blonde hair for their avatar, there’s often someone in the room who says, “but what if I have purple hair?”

That’s cool.

Wear it with pride — but 80% of people won’t ask this question or identify this need. Build for 80% of your users and don’t add a feature unless you can fully justify the time and expense required to create it.

It’s always better to spend less upfront and find out later that people are, in fact, clamoring for that purple-haired avatar.

You can then roll it out to your grateful users and show that you’re a live, responsive business that listens to its community.

You’ll avoid creating something that wasn’t needed and score Brownie points for fulfilling the request.

I’m STILL overwhelmed with features and options

Struggling to pick your core MVP features (even after rounds of real-world validation) means you probably haven’t narrowed in on your target user, or your lens isn’t narrow enough.

A record-keeping app for doctors is still too broad; think about what kind of doctors, in what settings, would benefit most from this product.

Are they radiologists, family doctors, psychologists, or pathologists?

If several of these specialists could benefit from the product, look to your strengths and interests. They can provide a good starting point.

You don’t need to build what you know, but you should be excited to interact with the community you’re going to serve.

If you love kids and understand the challenges parents face in medical appointments, you might want to focus on pediatricians and create a family-focused app.

Hone in on an increasingly specific user and don’t forget to consider:

A. Geography — where are your users located and where will they use the product?

Customer saturation in a physical location can be essential for some products.

Tinder would have nosedived if it launched with just 10 people in each city. The app needed a critical mass of living, breathing users in order to thrive in even a couple locations.

Facebook mastered Harvard before it moved on to other colleges and, eventually, the entire world.

Once you reach your saturation point, expansion can happen more organically.

B. Revenue models — who will pay for your app or how will it create profits?

Our hypothetical medical app might not fly if people aren’t willing to pay for a service that tracks and stores their records, or if physicians can’t work it into their billing models.

You might find that patients will pay for the app only if they are above or below a certain income threshold.

Money shouldn’t drive the service, but the supply and demand sides need to line up appropriately.

C. Interaction and community — does your app need to have a social element?

Many of our clients at Appster mistakenly believe that every app needs a built-in community.

That’s rarely true — and going social too quickly can create the dreaded Ghost Town Effect, where the lights are on but no one is logged in.

It doesn’t matter whether you’re still getting started or the community hasn’t caught on, people just see digital tumbleweeds.

It’s not good.

Think carefully before you add social elements to your product.

A ratings and review site might need social sharing functions, but a tax app can remain a thoroughly solo experience.

Wait — I still want to add a few more features

I get it. The urge to maximize functionality and get your money’s worth from the development process is strong. But please, resist — for the sake of your MVP, and most importantly, for your users.

Here are a few more reasons why it’s in your best interest to go lean:

1. You’ll flatten the learning curve

The more features you add, the more users need to learn.

That creates friction, and friction increases the odds that your app will get deleted. A strong MVP introduces 2–3 features you can master immediately.

Everyone is already overwhelmed and distracted.

Get users in, show them what your product is about and make them feel great about the download.

If it’s a financial app that helps people upload and organize receipts, don’t spit out a spending graph until they’ve mastered the basics. You can do that in a few weeks or add graphing functionality in a later version.

2. You can repeatedly ring the PR bell

Releasing new features slowly, over time, gives you a richer story to share with media and user communities.

You can talk about how your startup evolved to meet a user need or how the app is growing so fast that you’ve rolled out a series of exciting, new menu options.

Do it all at once, though, and you can’t keep extending the narrative.

3. You can capitalize on surprises

Launch with a leaner, thinner frame and you can see how users actually interact with the product.

Sure, you built a receipt-tracking app, but if it turns out your users want tax tools for small businesses, you can pivot accordingly.

You don’t have to course-correct in response, but staying small and nimble at the start gives you options.

Sometimes people show you what they want through their behavior and usage patterns, even if they weren’t able to express it during those initial validation chats.

4. Know when it’s time to release

The startup community likes to say that entrepreneurs should be embarrassed by their first products. After all, if you haven’t evolved past that initial release, you’re probably not launching fast enough.

This advice can sometimes feel a little ego-driven, but it does have merit.

As long as the buttons work, the screens load and everything is functional, there’s no such thing as an app that’s too small for release — if the quality is impeccable.

It’s better to launch with two excellent features than four buggy ones. Make your MVP awesome and tell users that more is on the way.

As Twitter co-founder Jack Dorsey said so eloquently:

“make every detail perfect and limit the number of details to perfect.”

Once your core features are as perfect as possible, it’s time to launch.

Release your hypothesis into the world and get ready to listen, learn and adapt.

Refine your work.

Re-frame the question again and put it back out there.

You’ll eventually find a solution that could revolutionize how we live, travel, love or eat.

You can start small and still go on to conquer the world.


Thanks for reading!

If you enjoyed this article, feel free to hit that heart button below ❤ to help others find it!


Originally published at http://www.appsterhq.com/