(2/3) — I spent 9 months building a B2C app full-time, here are 19 things I learned.
I am a first-time entrepreneur from Germany with a semi-technical background building a tech product. Around 5k users gave knugget a squeeze and we are currently at 100 DAUs — slowly but steadily decreasing… So, things don’t go particularly well. This what I learned! (Part 2of 3)
In the previous part I shared my mistakes and learnings regarding general Entrepreneurial Skills (⚙️ ). In this part I now walk you through the fallacies, misconceptions and other hurdles that challenged me during the Product Management (💻) of knugget.
Before starting to build knugget I didn’t know what the job of a Product Manager (PM) looks like — now I have the utmost respect for it!
Not only does a PM need to be proficient in a wide range of different skills and knowledgeable in many more fields, their product decisions can lastingly impact the future outcome of the overall business. Phew…
It was the first time for me to manage a tech product so to the seasoned PMs reading this: There’s probably not much in it for you 👋
For everyone new to the game: These are the key things I learned and I hope you can get an insight or two out of reading this.
Let’s get to it! 🤸
🛑 💻 Mistake 1: I thought tests are meant to prove my solution RIGHT.
This might come across as hair-splitting but to me, it is one of the most important learnings of the past months. Had I deeply understood this earlier, I might have postponed writing code a few more weeks to first get a clear understanding of whether what I want to build actually works.
I thought, foolishly, that tests are meant to prove if an idea can fly.
They are not. The intention is to find out why an idea would not fly. This is a significant difference because it changes the expectations of what a test is supposed to do and how to approach testing in general.
To build a growing, sustainable business a lot of things must fall into place. Hence, if you want to know if the business as a whole works, you have to build it out as this is the only way to eradicate all doubt.
In other words: there are numerous reasons for why a business can fail. Looking at it from this side has a significant advantge: To find out what makes it fail, you don’t have to build the whole thing. You isolate the reasons why it would fail and test them individually.
To do that, you are free to run a test that is very far away from the solution you envision, as long as the results prove one of your underlying hypotheses right or wrong.
In my case I thought that I have to build it to really know, if knugget will work or not. “Tests”, I thought, “only provide weak data that might serve as an indicator but will not reliably tell me if knugget will work.”
What I should have thought about are the reasons why knugget would not work, rank them based on their fuck-the-whole-thing-up-potential and work my way down from the top.
Yes, this is less fun than coding. Yes, this does not feel like progress. Yes, this can be discouraging at times. But it builds a solid foundation to build a solid business upon.
🟢️💻 Learning 1: Tests help me find out why my solution might FAIL.
🛑 💻 Mistake 2: I took false positives from users for real
At the beginning of this year, I made a LinkedIn video and people loved the idea behind knugget. 250 people commented that they want to test the MVP so I was pretty pumped. In the first week, we got 140 users signed up. Is it really that easy?
No (:
After the retention of the first MVP was pretty bad, I asked the users why. Most of them were very positive and “loved the idea” and “would use it if it only were an app”. Easy peasy I thought, you got to listen to your users and build what they want — an app we can build!
So we did. It didn’t solve our retention problem.
People are polite or (un)consciously portrait an image of themselves that not always aligns with their behaviour. Only a few OGs told me knugget doesn’t work for them ❤ It’s important to keep them around as long as possible (which isn’t so easy if your product comes short of fulfilling its value proposition).
🟢️💻 Learning 2: Only listen to past experiences of a user. Every statement about the future is overly optimistic and meant to make me feel good.
🛑 💻 Mistake 3: I overestimated the importance of good UX at an early stage
Our users wanted an app for two reasons: To not have to have their laptop close by when they read and to get push notifications on their phones to reread their knuggets.
I believed them, I made the same experience.
But I should have been more skeptical. If knugget would have solved a burning problem, they would’ve gone through the pain of typing up their knuggets on their laptop.
In other words: The channel or platform (email/web vs. app) is rarely the reason why people don’t use an MVP. There is a different problem which the users are not aware of or which they don’t want to openly communicate.
In this case: Most people don’t like to stop reading to write up a knugget — this is quite an effort as you have to condense it down while typing it out. Switching to an app did not make this much easier, going from 10-finger-typing to two thumbs.
Lastly, if you offer so much value that people go through a lot of friction to use your product, chances are much higher that they are willing to pay for it down the line.
🟢️💻 Learning 3: A crappy UX can be my friend: It filters out users with a passing annoyance which helps to find users with a real problem. And it can help strengthening the proof of concept.
🛑 💻 Mistake 4: We launched two tech products with little to no analytics.
For the webapp we had very basic analytics running and for the native app we added granular analytics a couple of weeks down the line.
We were aware of the importance of analytics but wanted to launch fast, so we prioritized it down. It would have made more sense to take one week to learn how to do it properly and set it up before the launch.
🟢️💻 Learning 4: Always launch with full-fledged analytics set up.
🛑 💻 Mistake 5: I looked for data that supported my hunch.
When making product decisions, I almost always ended up going with my initial hunch. I knew I need data to base my product decision on and went through different chats and charts to pick the sentences and KPIs that supported the hunch.
What I should’ve done is look for data that disproves my believe. Chances are much higher that I am wrong anyways and knowing that early on is super valuable. And if I cannot find much data that proves me wrong, my assumption ends up being much stronger.
🟢️💻 Learning 5: Don’t fall for the confirmation bias: Look for data that disproves the assumption first.
🛑 💻 Mistake 6: I didn’t talk to enough users in a structured way early on.
This is a short one: I had loads of chats with loads of people who liked knugget.
And I asked a few friends who read a lot how they go about managing their insights and challenges when it comes to knowledge retention.
I did not do a proper Mom Test before starting to build🙄
🟢️💻 Learning 6: Talk to more users in a structured way.
🛑 💻 Mistake 7: I didn’t organize my user insights.
I did not catalog the insights I got from users in a digestible and accesible way. I collected insights in different Notion pages and tables and aggregated them to make product decisions, but there was no real methodology or framework to it. Most critically, building an app for knowledge retention, I should have known that I will sooner or later forget what people told me which will weaken the quality of my decisions down the line.
To get the most insight out of it (and value the time the interviewees generously offered) I have to be more disciplined in managing the insights better.
🟢️💻 Learning 7: Organize user insights properly and make them easily accessible to go back to at a later iteration.
How about “Fail fast, reflect often” ?
I have built a little tool to help myself do these reflections regularly. It blocks my browser on Sundays until I wrote at least a few hundred words of reflection.
I played around to find the best set of questions and triggers for deep reflection of what happend in the last week, what could’ve gone better, etc.
And, most importantly, I want to have a seamless experience when doing meta-reflections. It was already super annoying jumping back and forth between four docs, trying to find the overarching themes and patterns.
I don’t want this shitty UX to stop me from getting the most out of quarterly and bi-yearly meta-reflections, so I started to design a seamless way to facilitate the monthly, quarterly and bi-yearly meta-reflections.
Wanna test it?
Please leave your mail (and answer a few questions) here so I can reach out :)
In the upcoming last part I will share with you a few insights regarding decision-making.
