How We Failed at a Startup – and what you can learn

White and Blue Monochrome Photo High School Newsletter.png

Be Our Guest is a feature on the EC blog highlighting thought leadership from our community – advisors, entrepreneurs, members, and more.

Today’s post is by EC advisor Greg Born. Greg began his career as an Air Force Pilot, then held leadership roles in both Operations and Mergers and Acquisitions at businesses such as GE, Oracle, Comcast, as well as a health and health-tech businesses – including Change Healthcare in Nashville. In all roles, his focus has been improving operational teams, connecting strategy and growth, and leading transformation. Helping it operate better. You can read his other entrepreneurship and leadership articles here.

I’ve been fortunate to have founded or helped lead 4 different startups in my career. One of those failed. These experiences were interspersed with working for larger (sometimes really large) businesses. The markets were just as diverse as the startups – falling into technology, healthcare, industrial. But there were a few things that held true and were the key success drivers. When these things weren’t the gospel, failure followed.

We Already Had Product Demand …. even before we created it.

There were just a few of us and an amazing idea, with big customers who already wanted it. On this “startup”, we were under a bigger business umbrella. They asked us to lead this startup and build the leadership team. It was a bittersweet opportunity. The “umbrella” business gave us the cash to start up, but had some very high expectations to move forward and create the business … with tight deadlines. Within two months we had a clear plan, hired a development team, and were starting to develop code which we expected to be a gamechanger in the marketplace. I was the #2 under the Startup CEO.

Adding More Complexity

Some challenges surfaced not long after – we had planned to integrate this into a larger application that was already available. The integration points that early diligence indicated were available, turned out not to be there. The (startup) CEO decided he would take that on and re-develop the other code, ensuring perfect integration points. I recommended we focus on our main objective that we’d been hired for, and work with others to get the integration points setup … but the CEO felt he could do it better. Not long after, he took on even more additional work outside of our original plans with the similar ideas of making it better (and thus the product better).

Challenges Surfaced

Soon after, delays accumulated. Resources were taxed. Deadlines were missed. Budgets maxed. Not one objective ended up being met. The umbrella business grew frustrated with lack of progress and direction, and eventually shut this initiative down.

Minimum Viable Product

We had failed to follow one of the most important ideas in starting up a business – simplicity. Our business became too complicated too fast. Even more so, we diluted our ability to execute. We didn’t focus on the right things. And lost focus of the MVP. Minimum Viable Product. We talked about this concept in depth early on, but lost focus with the CEO’s drive to take on the other work because he thought he do it better. Looking back, things would have been different if we had maintained focus on our key product plans.

A Successful Startup

I had created a business in my spare time years ago. It was a social network. The goal was to create something that would operate by itself (since I had a full time job). I hired a few offshore programmers. Drew some powerpoint diagrams for workflow, user interface, etc. And created a very simple online application. The interface was basic. The functionality was minimal. But a few users started to use it and give me feedback. It gave me the opportunity to test the idea, and tweak. I didn’t realize it at the time, but I had focused my attention on an MVP.

— My View of a MVP —
There are different definitions of a MVP – one view is that the MVP doesn’t need to be fully functional. I think you’ll put yourself at a disadvantage if you take this approach. My belief is to create a SIMPLE, functional and operational product / application / service that your customers can use …. then tweak from there. It allows you to rapidly iterate based on customer feedback (even if it’s a small cohort). Simplicity allows you to avoid many of the downfalls of making something too complex at first.

I got it out the door into users, and improved the product from their feedback. Tweak, repeat. Though I really wanted to deploy all the features and functionality I had in my backlog / roadmap, I really focused on getting something simple, that worked out the door.

Within about a year of regular updates, modifications, enhancements, user feedback, the website was getting about 100,000 unique users a month.

I tried my hand again at a new online movie and TV show search application called Again, the focus is basic functionality, make it work, get feedback, learn from it all, and make it better incrementally. Using this approach, I was able to quickly learn a few things which differed from my expected roadmap and customer usage. Here are a few examples:

  • Local vs International.

    • Expectation: majority of users from USA, so features were USA-focused with plans for international in the future.

    • What I experienced: significant organic international usage right after roll-out. I had expected the majority of users to be from the USA.

    • What I changed: modified the roadmap priorities to have more international features sooner.

  • Website Functions Would Be Easy to Use:

    • The website had only a few functions initially (simplicity), and those few features were the core of the website.

    • Expectation: I expected these functions to be easy and self-explanatory to use.

    • What I experienced: Most users didn’t use the functions, or if they did, they weren’t used as I had hoped.

    • What I changed: new feature to highlight these key functions and how to use them.

What I’ve Learned

We all hear about MVP. You may have read about it in The Lean Startup by Eric Ries. An outstanding read. This book lays out the foundation for creating a startup.

Focusing on simplicity doesn’t just apply to MVP or startups, as you grow your business, you’ll find that lots of times, you have amazing plans for growing, creating, managing – and often they are complex. Breaking that complexity down to “bite sized” chunks that are much more simple, may help you to achieve your goals.

Did you know the EC has over 280 Advisors?

If you’re an entrepreneur and are looking for more advice from Greg – or someone like him – check out the EC’s Advisor Program. Meet with over 280 mentors from all backgrounds, industries, and specialties. You can learn more here.

More news from EC