The pivots I made as the CEO of my Techstars-backed startup, and whether or not I'll do it again.
"To pivot, or not to pivot? That is the question." -Hamlet probably, if he were a startup founder
About two months ago, I closed my venture-backed startup BLOOP after 2 to 3 years of activity. The startup died as many do - we ran out of funding.
A week ago, I had an interesting conversation about my experience building BLOOP's software. It turns out my conversation partner is starting a company tackling the same problem BLOOP tackled -- saving and sharing information across multiple platforms via social bookmarks. Basically a revamped Del.icio.us that accounts for the modern information landscape and digital usage habits.
The conversation led to analysis and reminiscing about the 4 different pivots I made now with the clarity of having closed the company. During that time, after being backed by Filecoin Techstars, we pivoted with evidence from various market, product, financial, and technical variables with the goal of staying true to our North Star and optimizing feasibility and viability.
Looking back, I wonder if I would make the same decisions if I were building BLOOP now. In our case we were an early stage startup that has not yet achieved positive cash flow. For us, pivots are like amputations. Like an amputation, a pivot is somewhat traumatic -- it disrupts how the team works, and requires re-evaluation of our future plans from go-to-market strategy, product requirements, and positioning. But also like amputations, pivots can also save the company and allow the team to focus on what's working vs. what is not. Like, amputations, pivots must be done with careful consideration. The amputation metaphor is a bit intense by design to express how much EFFORT, LOSS, and sometimes PAIN it takes to make a successful, data-informed pivot.
This essay goes into how we used MVP's to test pivot viability, reflecting on the lessons learned, and considering whether each pivot was the right move. I'll include a summary of each pivot's hypothesis, hypothesis verification, and user/market research validation.
Pivots are like amputations. Like an amputation, a pivot is somewhat traumatic -- it disrupts how the team works, and requires re-evaluation of our future plans from go-to-market strategy, product requirements, and positioning. But also like amputations, pivots can also save the company and allow the team to focus on what's working vs. what is not.
This is a bit of a long one, so feel free to skip and skim around. :) I hope this can provide some insight in the way I made decisions, and help others in similar cross-roads.
Now, starting with our very first MVP --
MVP 1 - The Browser Tool for Auto-Didacts
Around the beginning of 2022, our initial focus was on auto-didacts who were predominantly white males in their late 20s to early 30s, passionate about note-taking. This niche group of "Zettelkasten" users were growing in exposure online, were deeply engaged in self-learning and note-taking online, and were paying for tools like Evernote, Pocket, Roam, etc. Furthermore, my masters dissertation on this subject verified the painpoint after user research with over 200 people who are in or tangential to this persona.
Hypothesis: Auto-didacts who already pay for a suite of productivity tools are missing a key tool to streamline their online browsing process.
Verifying the Hypothesis:
MVP: Developed a browser tool version of BLOOP, based on Chromium, with annotated browser history features tailored to the needs of auto-didacts looking to upgrade their note-taking workflows
Test: Onboarded 20 auto-didacts, with a demo including loadable and re-shareable packets of annotated browser history. Evaluated engagement levels and tool usage with a proof-of-concept assignment in the browser.
User Feedback & Usage Data: Track drop-off, feedback at various steps of the onboarding assignment, and the qualitative ways they interact with their own annotations vs. others.
For this MVP, one user actually used it every day for over a month. However, over the course of user testing, it became clear that the rest of the hypothesized target user group tended to have disparate and strong opinions of the ideal workflow - leading to challenges in creating a universally accepted tool. These varying and stringent tool requirements could not be met by our product at our early stage. The browser tool was missing crucial features and the ongoing changes in the Chromium platform made it difficult to implement necessary updates. Despite this, there was a clear signal of potential demand, suggesting that with more resources, this direction could have been successful.
It was a painful pivot due to the amount of resources we invested in the previous iteration, but it became clear it wasn't the right fit for our team. We decided to focus on an adjacent niche that had a narrower set of feature requirements - online community managers for open source projects like Filecoin, Holochain, and other Web3 platforms.
MVP 2 / Proof of Concept (PoC) - The Web3 Community Manager & Creator Pivot
Since BLOOP was part of the Filecoin network, we had GTM opportunities and easier access to various Web3 community managers facing a similar problem as the auto-didact user group. They were also using convoluted workarounds for managing data dispersed across places online. Web3 community leaders from Handshake, Filecoin, and other Web3 communities showed interest in paying for an effective tool that helps them manage news across platforms. We hypothesized that BLOOP, as a collective intelligence tool, could streamline the dispersed information in these communities.
Hypothesis: Web3 community managers are missing a tool to manage commonly asked questions and up-to-date expert resources.
Verifying the Hypothesis:
Proof of Concept: Based on interviews with Web3 community leaders, we found that the main functions they seek are "save" for relevant resources, and "search" for their previous saves. In a two week sprint, we developed an early version of BLOOP Search + BLOOP bookmark and presented it to a Web3 conference and five community managers from 3 different Web3 communities.
Test: I manually populated BLOOP Search with relevant resources in the different Web3 communities, iterated on the onboarding process via a workshop with conference attendees, and onboarded 5 community managers with a demo use case.
User Feedback & User Data: Evaluate channels to overcome the "zero-to-one" challenge in BLOOP's Network Effect, especially in context of existing workflows. Collected feedback on the tool’s usability both synchronously (via in person tests or calls) and asynchronously (based on demo-use cases).
The PoC was not high fidelity enough to fit into community managers' existing workflow, leading to high drop-off rates after the initial demo use case for all but one user. Looking back, perhaps its low fidelity caused us to miss the window of opportunity to build network effects with these users. However, we discovered the crucial feature for this user group -- Discord and Slack integrations. We were excited to develop a tool that could optimize an enterprise workflow while still prioritizing the quality of B2C/B2B2C user experience. Hence the next MVP:
MVP 3 - The Discord Bot Pivot
Hypothesis: A Discord bot would appeal to Web3 communities and other online groups using Discord for communication, providing a seamless way to manage and share information within the platform.
Verifying the Hypothesis:
Launch: Considered developing a Discord bot as a simpler, more integrated solution.
Usage Data: Planned to monitor adoption and engagement levels within Discord communities.
User Feedback: Intended to collect feedback on the bot’s functionality and its impact on users’ workflows, comparing it to the broader web tool.
At one point, we considered developing a Discord bot. This pivot seemed promising because it addressed immediate needs within Web3 and other online communities.
Web3 communities and other online groups extensively use Discord for communication and information sharing.
There was a clear demand for tools that integrate smoothly into Discord’s existing workflows.
Discord could be a great entry into the social messaging add-on space. (Read: bots and API's and integrations into Slack and other messaging apps)
However, the idea of limiting our product to a single platform was misaligned with the North-Star of a cross-platform tool. Additionally, sticking with this direction would tie BLOOP's long-term viability to the continued consolidation of communities on messaging apps like Discord. I wasn't so sure if this would be a new pattern, or just a trend. We decided to use what we learned to focus on a different user group, allowing us to create a web-based solution that could cater to a wider audience, with wider applications.
Final Pivot & production grade launch- Shifting to Gen Z Users
Next, we pivoted to target Gen Z users based on changing search habits, favoring social platforms over traditional search engines.
MVP 4 - PWA (Progressive Web App) with mobile focus
Hypothesis: Gen Z users would prefer BLOOP as a social search tool due to their changing habits towards social media platforms over traditional search engines.
Data Supporting Hypothesis:
Research indicated Gen Z’s increasing reliance on social platforms for information.
Gen Z users are more tech-savvy and use multiple platforms for learning and information gathering.
User interviews indicated a market gap in SHAREABLE collections of curated content, as Gen Z's share content across apps and some want a way to separate topics/groups.
Plan to Verify Hypothesis:
Launch: A low-fidelity web app with a Pinterest-like interface.
Usage Data: Tracked user engagement and drop-off rates for both iterations.
User Feedback: Conducted two rounds of user tests, iterating on the interface based on feedback, and observed usage patterns among 20 beta testers.
We learned that the design patterns we used (Pinterest as corollary for curating content) was ill-fitted to this use case. We originally selected the PWA format to speed up the MVP launch, as well as remove downloading as a barrier to onboarding. However, we found that this severely limited our ability to approach native-like usability. This technical decision caused high drop-off rates after 2 to 3 saves. Looking back, this outcome is obvious.
The good sign though is that there was ample interest for a tool like this that prioritized sharing. So we moved on to iterating for a production-grade app while building the BLOOP youtube channel.
Production-grade app - Mobile app + chrome extension combo
We tested few different design patterns from save/share functionalities on social sites like Twitter, Reddit, and Tiktok, before settling on BLOOP's own design system. The alpha and beta testing leading up to this version also allowed us to narrow the target persona.
Hypothesis: Young Gen Z involved in entrepreneurial or ambitious learning pursuits, would consistently use BLOOP as a tool to manage information from multiple platforms.
Data Supporting Hypothesis:
Previous iterations showed promising engagement from young, ambitious Gen Z males.
Identified a subset of users who were consistently using the tool across mobile and browser platforms.
Plan to Verify Hypothesis:
Launch: Developed a final iteration combining a mobile app and Chrome extension with refined UI/UX based on previous feedback.
Usage Data: Tracked long-term usage and engagement patterns via user follow-up, tracking data in SQL databases / internal platforms
User Feedback: Continuously gathered insights on user experience, refining features and messaging to enhance retention and satisfaction.
This version actually found a 10% retention rate amongst the beta testers, with 2 to 3 people using it weekly for over 3 months. Despite some initial success, we faced internal team issues and ran out of money leading to the public launch. The startup’s sustainability was compromised, leading to the decision to sunset it... at least for now.
Reflections and Lessons Learned
Looking back, each pivot (or should I say MVP?) had its own merits and challenges. The major lesson was the critical balance between user feedback and the feasibility of product development. Pivoting too frequently can dilute focus and resources, yet sticking too rigidly to a failing plan can lead to a dead end.
User Feedback giveth and taketh away: Every pivot was informed by extensive user and market research. This iterative process of building, testing, and refining based on feedback was essential, although not every iteration was a success. I needed to be ruthless (but meticulous) in how I used results. If user feedback was truly bad, I needed to kill the previous pivot.
Resource Management: Effective pivoting requires careful management of resources. Our limited funding meant we had to make tough decisions on limited trials about which pivots to pursue. More funding might have allowed us to validate the final pivot at larger scale.
Vision vs. Practicality: While having a broad vision is important, being practical about immediate needs and limitations is crucial. The Discord bot could have been a sustainable product if we had focused on it without the ambition for web & cross-platform integration right away. However, the balance between the two depends on the nature of each company. In our case, our specialization lied elsewhere.
People and team: Towards the end of BLOOP, some hiring decisions backfired. Despite having some early promising results with the Gen Z users, internal issues prevented us from fully capitalizing on the opportunity. I learned a lot about managing expectations with different working styles, hiring the right people, and the challenges of offboarding.
Market Timing: I sometimes speculate if certain MVP's would've yielded different results if launched at different times. For example, the browser tool might have succeeded if launched a while after major Chromium updates. Or other pivots might have worked out if we balanced fidelity with a window of opportunity. It's important to align product development with market readiness.
Conclusion
BLOOP failed. If I could do it again, would I like to pivot less? Yes. But reviewing the user research and usage data we had, I still believe I made the right decisions.
Pivoting is an integral part of building a product. A lot of discourse encourages ruthless pivoting and MVP's as lo-fi as it gets. Both are necessary, but can have serious downsides. Ruthless pivoting can lead to resource scarcity. Lo-fi MVP's can miss a rounded-out experience to fish in important users -- missing a window of opportunity.
I recognize this conclusion is not so cut and clean - "Do this to succeed! Do this to avoid my mistakes!" And there's a reason for that.
I find that the best applications of design research & product management tend to be more nuanced than at first glance. Case studies, rather than rules of thumb, are more useful to build deep understanding of how product decisions can play out in a changing market. In that sense, I hope this essay is helpful as a tool to add to your tool kit.
Comentarios