Not having product / market fit is the chasm of struggle

Sisyphus is a character from Greek mythology who is condemned to spend all of eternity rolling a giant boulder up a hill only to have the boulder roll back down at the end of every day. Each morning Sisyphus is confronted with the endless, repetitive, and futile task of rolling the boulder up the hill again. 

I’ve been there.

In the beginning

The inspiration for Foundations came during the pandemic. During 2020 our services business was thriving and we were rapidly validating and solidifying our product / market fit methodology. We were having seemingly identical conversations with founders and founding teams and stumbled upon a common thread running through all of these conversations. 

Suddenly everyone was at home without a series of endless meetings to occupy each day -  and everyone was staring at their computers (and themselves in the mirror) and asking the same question - am I building the right thing? 

Am I building the right thing was the name and URL of the initial MVP for what is now the Foundations Plans product. Built on Bubble and tested with my female founder cohort from Grand Central Tech, consensus was that having a tool for founding teams to set and share their product roadmap with confidence - without needing a background in product management or an expensive head of product - was valuable and useful!

Good space, bad solution

We successfully validated the value proposition of the solution. We did not successfully validate the solution itself. Unpacking the difference between a value proposition and a value proposition embodied in an MVP is very difficult. As an aside this is entirely what The Lean Startup is about and yet also fails to reliably teach. 

There was a lot that was obviously not working in the Am I building the right thing MVP: 

1. The name was cumbersome. 

2. The UI was unironically reminiscent of Mario Brothers.

3. The workflow was clunky.

4. The original output plotted feature sets - what in JIRA terminology would be Epics - onto a large pair of grids.

5. The two grids had different axes so where something was plotted on the first versus the second grid had an entirely different meaning that wasn’t intuitively obvious. 

6. Sections of the grid summarized our assessment of the feature set’s value and recommended next steps - ranging from do not build (dark reds), to do more research (light reds / pinks), to build it fast (greens).

Through a combination of using the tool every day and visceral tester feedback, where we landed was that the UI / UX was a blocker for usage. The tool looked and felt so bad that we believed that a rebuild was essential prior to actively engaging more users. 

Implications of hearing wrong 

We predictably made the most common mistake that first time founders make. We took a little bit of positive validation on the value proposition and a lot of obvious surface level problems with the MVP and ran out to build a better version. 

We incorrectly diagnosed Bubble as the issue - and Bubble was an issue - but getting people to actively use Am I building the right thing was a larger and more complex undertaking. We didn’t figure this out quickly enough because we did not get people using some version tool in its current form. Instead we: 

1. Changed the name to Plans  

2. Completely redesigned the UI 

3. Streamlined the workflow using well known and accepted paradigms like Trello’s Kanban board
   
   

   

   
   

4. Simplified the output to be what people were expecting - a roadmap. The roadmap prioritized what to build and in what order including what to research further. It left what not to build off underneath categorized into Don’t build and No user need defined. 

5. Used one expected axis showing time to build a specific set of features enabling a specific user outcome.

6. Color coded the roadmap to coincide logically with recommendations like: 

• Pink: Good space, bad solution. People want to solve this problem just not with your current solution - invest user research resources here and do more customer discovery to understand and rethink how you can more effectively solve their problem!

• Light red: Solution in search of a problem. This is an idea people are interested in but they're not sure what to do with it - invest user research resources here and do more customer validation to identify the specific problem this solution solves or could solve for customers!

Throughout this process I had the cognitive dissonance that many first time founders have. Mine went like this:

Of course founders know the answers to these questions and they want to create their roadmap through a rigerous analysis to deliver clear outcomes for their customers!

Talk is cheap and a word on perfectionism

During the period of our services success in 2020 and 2021, we frequently discussed Am I building the right thing with our clients. We further validated the concept of a tool that asks four questions and then creates a product roadmap that lays out and communicates the logic of what should be built, why, and in what order as valuable and desired. 

What we still didn’t do was get our clients using some version of the tool. We had deemed our Bubble MVP too ugly and clunky and we hadn’t gotten out of Figma into a new code paradigm. We clicked through the Figma prototype on Zoom and got lots of oohs and ahhs but that really amounts to nothing in the end. 

We fooled ourselves into believing that we were still getting validation that the concept was wanted and needed but we weren’t actually validating the solution in form or function. 

Nor were we getting to the heart of what the real blockers were - that the questions were too hard and the answers were not going to prioritize anything - because we were being paid in a services engagement to do this work. Our services work handicapped our product learning.  

Optimistic ignorance explains why all the time we spent building an audience and pulling in users who weren’t our friends or clients was also wasted. Although we amassed an Instagram following of 1200+, an email list of 350+, and 200+ account creations we ultimately failed in both retention and referral. 

We did not find product / market fit. We did not create a self-sustaining business. We did not pass Go. We did not collect $200. (Actually we made a few hundred dollars but all paid subscriptions are long canceled.) 

Mistakes all the way down

When prioritizing major UX / UI improvements we myopically focused on surface level problems like that the platform was wonky and didn’t support good design paradigms and remediating our own basic and embarrassing UX errors. This distracted us from getting to the the deeper, more foundational issues which became glaringly clear upon rebuild: 

1. Mapping features to user outcomes is not an intuitive thought process and it’s not easily translated into a UI. 

   
   

2. The questions founders needed to answer in order to arrive at their prioritized roadmap are challenging. 

   
   

3. Founders are not making their roadmap prioritization decisions off of these questions: 

   • Does the user do this <activity> today? 

   • If so, how? 

   • How much of your customer base will adopt this feature set?

   • How long will it take you to build this feature set?  

The truth was founders had much more trouble thinking about user outcomes as tied to features and answering these questions then they did navigating any UI. The product was too hard to use conceptually and no amount of good design was going to resolve that. 

The real truth is that many founders - especially of venture backed startups - aren’t spending their time answering these questions and are instead setting (and changing) their roadmaps based on what their investors suggest or what a large client or few tell them they will pay for. 

The insight

Accepting this reality is a big part of what pushed me to look for a middle path between venture capital and bootstrapping. I still think that understanding the answers to some version of these questions around the importance of the problem, competitiveness of the market, anticipated product adoption, and level of effort are the right ones to ask when building a product. 

In venture funded startups these questions are not prioritized because founders are being pushed to move through funding rounds toward an exit above all else. Presenting the picture that growth is happening and scale is right around the corner is front and center. This means skipping over product / market fit if necessary and often putting scalable before self-sustaining. More people touching a product is better than less people who value it deeply. 

Alternatively in the bootstrapping paradigm, it’s far too easy to lose focus and slip into non critical path work that you feel is moving in the needle but that is in fact wasting your most important resource - time. 

For extremely different reasons, many venture backed and bootstrapped startups end up in the exact same place of never validating their product or business model with enough people and thus never achieving product / market fit or a self-sustaining business.

Time heals all wounds and compounds all mistakes

We let a lot of time go by between the Am I building the right thing MVP, feedback from the GCT cohort, and the rebuild. It took us about 5 quarters between initial MVP testing and V1 product release in early 2022. 

This is the true peril of bootstrapping - the time lapse between initial feedback and iteratively completing a turn of the product. If you are ambitious enough to bootstrap in the first place (without being independently wealthy) you will have another job or business. Inevitably when that job or business starts doing well, you will be distracted doing that work well. Even if you think you’re keeping your eye on the ball it’s easy to look up and have a year gone by. 

More than that - even if you’ve rigorously documented your initial testing feedback, the longer the amount of time that goes by, the more likely you are to interpret it differently into the rebuild.

In our case, we had the opportunity to work with a titan in the women’s health care space. This partner was extremely strategic, aligned with our value system, valued our expertise, and promised to more than fund our rebuild and marketing of our software product - and it did. 

The problem was we traded our window to engage and iterate with our target audience of founders for capital. 

I fought the law and the law won

There is a fundamental misalignment between how we thought products and businesses should be built and how they were actually being built by our target customers. 

Because we weren’t helping venture-backed founders with their most pressing need - demonstrating growth even at the expense of finding product / market fit - we couldn’t capture the ever fleeting, rare commodity of attention. Attention is what might have helped us iterate to the right solution.  

Instead we started at Good space, bad solution and ended up with Solution in search of a problem. 

Tech is also cheap 

We know from hands-on experience that building technology has never been more affordable. We spent less than $100,000 building and marketing an MVP on Bubble through two full product builds of Plans and Tests on React + Digital Ocean + Firebase + postgres DB + Chargebee + Stripe + Data Dog. Our infrastructure costs about $200 per month to keep both the Plans and Tests products and the Am I building the right thing MVP live. 

But that doesn’t mean all products should or can be purely bootstrapped - building the wrong thing cheaply is still building the wrong thing. Plans and Tests remain unvalidated products with unproven business models. The only real upside - aside from the learnings - is that their failure to find product / market fit has never had any adverse impact on salaried employees, gig workers, small business owners, our customers - or the economy writ large. 

Trading time for bootstrapped money is as much of a product killer as trading product / market fit for venture money - it just happens more quickly and obviously and with less collateral damage. In the end the pain for the founding team is probably the same.