Photo courtesy of pixabay.com A prospective founder must ask: is my idea viable? But this question also must be addressed throughout the startup’s life. This story is my cheat sheet for evaluating the viability and strategy of startups. I spent 10 years with (now Pivotal), working with hundreds of startups. Some like TrueCar, TaskRabbbit and Twitter matured and succeeded. Others did not. Now, I am an operating partner at an angel fund, leading two startups and advising others. These experiences have revealed insights and patterns that help me declutter the confusion and distractions common in startups. Pivotal Labs Of course they will come I was sitting in , listening to a founder tell me about her startup. I’ve had these conversations before and they can be challenging. The founder is seeking advice and I want to help. But it can be hard to digest her idea, its obstacles and opportunities, so that I can discover the key questions that’ll lead to a productive discussion. Verve Coffee One day, during a different conversation with a fledgling entrepreneur, I had a thought. This thought became the basis for my cheat sheet. I had been invited to give a talk at a local university entrepreneurs club. While socializing after my talk, a young man described his startup idea with such confidence, I was reminded of a key line in the 1989 film, . “If you build it, they will come.” The young man, despite some glaring holes in his premise, seemed to assume success once he built his vision. Field of Dreams I don’t fault a founder for such conviction; if you don’t believe in your idea, ? why would anyone else But it’s better to be a skeptic and ask, “If we build it, would anyone care?” It’s this question that led to what I call the . why The Field of Dreams Test The Field of Dreams Test The Field of Dreams Test is a diagnostic tool that helps me organize key questions and considerations about a startup. I focus on these three areas: user pain user experience economics User Pain Instead of just describing the primary use case or the user’s problem, I frame it as a “user pain”. People are more likely to seek and accept help for pain than for a use case. What is the frequency and severity of the pain? Can the user live with it? Is it an inconvenience or something they need addressed? What are the root causes? What are the symptoms? Diagnosing a root cause can be difficult, but only addressing symptoms is problematic. A user will abandon a “solution” that addresses a symptom. . Sticky experiences address a root cause For example, understood that a root pain with digital photos is their permanence; users don’t want every photo to exist forever. If Snap only addressed symptoms, they might have offered better sharing permissions and security instead of the expiring photos they’ve become known for. Snap(Chat) User Experience I suggest thinking about instead of defining a . It’s too tempting to dream about the future when designing a solution, detached from the user’s needs. user experience solution Look at any interaction the user will have with a startup’s product, beyond just the application’s user interface (UI). Consider Uber and their approach to hailing and paying for a taxi. The user experience is the main combatant against overcoming inertia. People live with many inconveniences and pains, adopting and relying on workarounds. Have you ever watched bad TV because the remote control was out of reach? Remember that the . user experience needs to be compelling How does the startup address the user’s pain? Is the experience good enough to displace alternatives? How is it different? Is it a joyous experience? For this exercise, I’d avoid detailed designs. Focus on a succinct summary of the user journey and how this resolves the user’s “pain”. Economics A startup should have a hypothesis for economic viability. Before worrying about detailed business plans, a startup needs to assess the basics: cost, growth and success criteria. plausible Costs Are your costs viable? What would make them viable? What is the effort for a user to switch to the product? What is the learning curve? What is the overhead of disrupting existing habits, importing of data or building a new network? What are competitors’ costs? Is it easy for a competitor to copy the startup’s ideas? Growth How might user adoption grow? Is there natural virality or network benefits? (example: photo sharing) Success What defines a win for the user? For the startup? Do these conflict or support each other? The Field of Dreams Test doesn’t determine success or failure. It is a starting point to organize a discussion or a plan. These are not new ideas nor the only ones to consider. But focussing on user pain, user experience and economics can clear your thinking. Applying the Field of Dreams Test I have multiple Google accounts. I use Google Gmail, Drive, Calendar, etc. Sometimes I can’t remember where a piece of information is. Or I want to find all my data on a topic. I’d like to search my data, across all Google products (and ideally, across all my Google accounts). The is clear: why must I search 20 different places for data that is all mine? (I have a lot of Google accounts.) I can imagine a splendid , where I have one search box and I can filter results, quickly locating information across multiple, heterogenous sources. user pain user experience But , specifically costs, the idea. It isn’t my costs of building nor operating such an application, but it is the low cost for Google to add this functionality. economics kill Maybe Google has a good reason for omitting this feature. Maybe it isn’t a priority for them. But any success my service enjoys is market validation that tells Google to add the feature and my startup. end Mailbox: A Mixed Example launched in February of 2013 and Dropbox them in March of 2013. I’ll highlight a few aspects of a Field of Dreams analysis for Mailbox. Mailbox acquired Mailbox observed that people struggled to keep up with email. Furthermore, they often used their email as a todo list, though it was a kludgy tool for such a use case. User Pain: Users loved the UX/UI of Mailbox. (There were by the time of the acquisition.) The app wasn’t just an email client, but a tool optimized to turn email into a todo list and help clear the user’s inbox. User Experience: 1.3MM users on a waiting list MailBox UI, from Slashgear article The insights about the pain of email, combined with the Mailbox approach, users’ emotions regarding email. They went from feeling to and organized. transformed overwhelmed empowered The economics of Mailbox are . Mailbox wasn’t an email host service, but allowed users to use their Google Gmail. This lowered the friction of user adoption, but if Google cloned the Mailbox experience, there would be for users to with Mailbox. Economics: murky little incentive stick Google, in my opinion, did just that. implements many of the ideas of Mailbox. I wonder what would have become of Mailbox if they were not acquired so quickly. Inbox by Gmail The Mailbox example shows that the Field of Dreams Test is a heuristic for assembling evaluation criteria; it isn’t an algorithm that provides a conclusion. How will you use this tool? The Field of Dreams Test is an approach to evaluating problem, solution and effort, in the context of startups. It has guided me when hearing pitches and helped me advise founders. It can be applied to evaluating competitors or alternatives options users may have. If you follow ’s beachhead guidance (segmentation approach), you can apply the Field of Dreams test to the beachhead / segment. Crossing the Chasm The Field of Dreams Test isn’t a one time exercise. It can (and I think should) be used iteratively. It can help founders resolve the see-saw deliberation to start a company or not. And if she did commit to the wild ride, chasing users and investors, and playing whack-a-mole with perpetual crises, it can help her sort through the noise. I encourage you to let me know your thoughts, stories and any tips you might have. Please ♡ this post and follow me for updates — on Medium or on twitter ( ). csepulv

Dropbox

Google

Techcrunch

Twitter

Uber

Share Code between React and React Native Apps

Just Ideas

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

If we build it, why would anyone care?

If we build it, why would anyone care?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Share Code between React and React Native Apps

0 to $2000 MRR in One Month - Lessons Learned

I Built a Product with a No-Code Tool and Pitched it to VCs

'Smart people with bad ideas can always pivot.' —LA MP Mark Tung

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

Share Code between React and React Native Apps

0 to $2000 MRR in One Month - Lessons Learned

I Built a Product with a No-Code Tool and Pitched it to VCs

'Smart people with bad ideas can always pivot.' —LA MP Mark Tung

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps