Six takeaways from building my startup #1
If you could describe your 2023 so far, which words would you pick?
I have spent the first 6 months of 2023 working on what I now call “my startup #1”. Having now moved to a new chapter, I look back on my journey through a new lens. At Hemy, we were building an assistant for sales reps which took over repetitive tasks, starting with sales follow-ups. This piece is my honest attempt to write down the experiences and lessons I am taking away from this formative experience. The good, the bad, all of it.
They say the only constant in life is change. Or as Benjamin Franklin famously stated, “When you are finished changing, you are finished”. So let’s embrace this change, shall we?
1. “Being right” in a pre-product phase
There is a famous Amazon leadership principle which encourages employees to “be right, a lot” - meaning they should seek for truth in order make the right decisions on behalf of customers. Amazon goes on to describe it as “seeking diverse perspectives and work to disconfirm beliefs.”
In the world of endless problems, how hard can it be to learn about them? Turns out, it’s pretty damn hard. Throughout the early stages of ideation (and moving forward), my number one job was to gain full clarity on the problems users have. What is the job they’re trying to accomplish? What is the desired outcome? What pain do they experience as they go from A (initial outcome) to B (desired outcome)? How does the current process make them feel?
I have found following this structure useful for gaining clarity on each problem. For every target persona, I would fill out the following sentence:
As a ……, I’m trying to do ……, but find it difficult because ……, which makes me feel ……, if only there was a way I could……
Forming this one sentence gives insight into the type of persona you have learnt about, their JTBD (Job-To-Be-Done), pain points, emotions and feelings resulting from this pain, and the desired outcome.
After getting the first feeling of users and their problems, I would list down potential solutions — each with a problem description, underlying hypotheses, confidence level, and actual people who would benefit from it. Looking back, I still believe this is a great way to do data-driven discovery.
Just one thing…
If I were to start again today, I would change the way I interact with users from day 0. Effective communication is hard everywhere, but especially so in early discovery. On top of that, many people complain about things that turn out to be no problems at all, so you have to be extra cautious here.
If you’re into building things, you’ve probably heard about the Mom Test. I find these insights by Rob Fritzpatrick useful to get to the “real problems”:
Ask about the problems people had the past week or month instead of “usually”- it forces people to think harder about a real problem they actually had to deal with recently
Ask if they actually tried fixing this problem before — if they haven’t, it is probably a sign that it didn’t frustrate them enough to actually try fixing it
Don’t pitch your idea, you could fall for biased confirmation
Something that Bob Moesta suggests in his brilliant read Demand-Side Sales is also useful during user interviews: giving context and setting the tone. What were users surrounded by when they were facing a certain problem? Who were they with? Adding details to your questions may seem irrelevant, but it helps users remember the setting and pivotal moments that move them to certain decisions.
In addition, what I should have done more of is ask for commitment. Having done sales with a mid to long sales cycle before, I was too used to getting the next step: next meeting, demo, contract signing. But when you don’t have a product yet, it can be a dangerous route. So you need to make up your own rules: what is the commitment you’re seeking to validate or de-validate your idea? Can you get these people to co-develop with you? Or pay $1, $15 or $1500 for your product or your service today?
Takeaway for self: Ask real questions, not hypothetical ones. Test the intensity of pain. Add context and details to the situation users are in when they were experiencing a problem or deciding how to solve it. Learn about the current way of doing things. Ask for commitment right away, do not wait for some crazy great milestone to do so, whether it is surpassing 10 or 20 interviews or having THE product (hint: you should not have a product you are proud of in the early days). You can probably talk to someone for 10 mins today and ask if solving any given issue is worth $50 to them. The good news is that you don’t even need an answer — you will be able to tell based on the reaction on their face.
It may sound obvious on paper and yet too many entrepreneurs shy away from these conversations in practice, hoping that shipping new features will eventually get them somewhere. Unless you are a genius or somehow extraordinary, having hard conversations is the only way to learn.
2. Insights turning into products
Back at AWS, a mentor once told me: “There will be lots of noise around you. Your job is to decide what information is relevant, and tune down the rest.” I feel this rule applies even more so when building something new.
There comes a time where one has to make a decision what product to build. Perhaps the most difficult decision in anyone’s life who is responsible for driving their business forward — PMs, founders, team leads.
After 60+ interviews, I ended up building three no-code prototypes based on the insights gathered. I wrote down user stories describing an early prototype: the problem it addresses, the minimal viable solution design, basic characteristics, product flows and potential risks.
Looking back, user stories were a great exercise to gain full clarity on what needs to be built. I used apps like Glide, Figma and Bubble to built my prototypes, and for my personal taste, Glide worked out best in terms of ease of use and the time I needed to build something, with Figma still doing a much better job at guiding one from no-code to real code.
Takeaway for self: Initial excitement for a prototype != promising idea. I interpreted much of the early feedback as positive simply because someone was excited, and declined ideas where people showed little excitement. The truth is, just because someone is excited about X, does not mean they will actually use it. There may be many reasons for it: they love the idea of having it in theory or find the tech behind it cool. What I would do is, well, ask for commitment. If shipped today, what problem would it solve for them? What outcome do they hope to achieve? What does it take for them to make the switch vs. the incumbent solution or way of doing things?
These questions are harder to ask, but they help one break through the noise. You may experience euphoria to see people excited (who wouldn’t?), but believe me — it is not what you want. As a founder, your job is to find the real business opportunity. Decide what information is relevant, and tune down the rest.
Blue ocean vs. red ocean schools of thought
When evaluating ideas, I hardly ever thought about being in the blue vs. read ocean — I just cared about building something people want (the popular YC advice, I know — but it’s just too good!). The sales tech space is extremely saturated, so it felt like wherever I looked, it was red ocean. And yet, I somehow managed to find a niche that seemed unfilled at that time, at least from what users were telling me. I thought by being in a busy market with a “new” type of offering, I would somehow be different and easier to adopt.
How could I be wrong? Being in the blue ocean is great, isn’t it? Less competition, more potential to grow. Not quite always the case — I recently read this post by Melissa Kwan and found her view refreshing:
Takeaway for self: Would I choose to be in the blue ocean market again? Probably yes, although certain things need to be true:
It’s a hair-on-fire problem and people invest efforts into solving it today
Replacing the old way with the new has a clear RoI “soon enough”. What is soon enough? It depends on the industry, though it’s fair to say that users are more likely to switch if the new way leads to immediate value
The timing needs to be right. Many “new ways” are great, but people and organizations are just not ready to switch — either because there is no system for adopting new ways, the turning point is too hard to reach, or simply because the market conditions keep budgets tight.
3. Building, measuring, learning… charging!
As you may have guessed, I ended up building a product that gained most excitement. I saw how enthusiastic people get, and could not wait to ship a working version of that and hear what they have to say. We ended up building a very simple first version of the product and searched for feedback.
The tricky part is, when things are so early, how do you measure success? But if you cannot measure, you cannot manage, as the saying goes — and it’s as true in startups as in established orgs. Ultimately, I worked with the following:
Co-development commitments
Sign-ups (waitlist, dev updates and later on — for the product itself)
Conversion from free to paid
What I felt we actually did well here was getting partner commitments. Our conditions to become a co-dev partner were:
User’s buy-in to contribute 30mins per week to give us feedback
Every user had to bring 1–2 more participants from the same org
Decision-maker (DM)’s buy-in for their folks to participate — we had a meeting with each of them to ensure they are in the loop
Having multiple people involved helps you de-risk your partnerships and protect your early product. In our case, this was extremely useful as right about the time we starting co-development, massive layoffs started happening. By having built relationships with multiple people in each org, we could proceed despite this fact (although it was obviously still not a great situation). But it could have been much worse and I am happy we did it.
As the saying goes, it’s better to have 10 people who love your product than 100 people who like it. Keeping the circle of initial partners small is definitely beneficial, but also means it’s all the more important to choose them wisely - ideally, they should fit into a single Ideal Customer Profile.
So, when do we monetize?
Like many other fellow founders, we took too long to set a price tag. “Let’s build this feature first”. “We should have better onboarding, one cannot experience value without it”. There are thousands of reasons why one should not monetize yet, and these reasons never end. As stated before, if you want to do the right thing in the early days, you should not seek for feeling proud of your product. It needs to be scrappy in the early days, because it means you’re learning a lot with few resources. In the early days, it’s about accelerating the learning curve so you can ship the best product later.
Even with a sales background like myself, once I started building a product, it was just too easy to obsess over all the features I wanted to ship. I would ask folks what other things they cared about, when in reality my #1 job as a startup founder is to solve just one issue, but do it well.
Takeaway for self: Sell first, then build. Charge latest while you are still building. In fact, I would even go this far and say most founders do not monetize early enough and most are still charging too little. It is okay to monetize while you’re still learning — how else will you know you’re focusing on the right problem? You certainly don’t want to learn everything about a field where no business can be built. I found this YC talk on startup pricing valuable — it does have limitations, but the idea here is to get into the mindset of charging. It may feel uncomfortable, but let’s face it: we founders already picked the most uncomfortable route there was, so we may as well make real effort to get to the desired outcome.
4. Telling people about my product
You likely find yourself hearing the ultimate question, “What are you working on?”, at social gatherings and casual meetings, and guess what: if you don’t talk about what you do, well, none else will. One of the biggest downsides of entrepreneurship is the loneliness you experience: you spend hours learning, building, sharing and you do most of it either alone or in a very lean team.
I found this question draining after the first few times, but changed my mindset around it and realized it is a great opportunity to:
Practice my elevator pitch in 10 seconds. I wanted people to instantly understand what we do
Spread the word. Chances are, these people know someone who may be affected by this problem and happy to connect you. There are many folks out there who genuinely want to help — take everything you can!
Talking about a problem I am solving helped me learn more about them or other problems. People would hear I am solving X, and they start seeing me as someone who likes solving issues. So the next time they experience something, they would approach me with their problem — or even mention a problem they are having right on the spot. Talking about problems is a great conversation starter, great way to get to know people and their true frustrations, and the best way to avoid boring small talk :)
Surprisingly, we got lots of inbound interest simply by talking about what we do. Unless you have strong reasons to build in stealth, it’s never too early to share your thoughts and ideas — in the world of paid ads and shiny career updates, hearing about what someone is solving can be extremely refreshing and sends the right people your way. In other ways, you should always be launching (our Product Hunt launch below), a very scalable way of telling everyone you know about what you do. I only wish I had launched earlier!
Takeaway for self: Spread the word about the problem you are solving, and measure the interest you receive to validate your idea. Talk to strangers or friends about what you are building and create a scalable way to share more of it (LinkedIn, newsletters, Twitter). Make it your daily habit and it becomes more fun as you go. It may be uncomfortable, but as we have learnt already — if you’re comfortable, you are not learning and not growing.
5. Building a startup vs. building a business
Too many folks focus on building a startup rather than building a business. The tech scene has led to the rise of a vibrant culture where one can attend a talk, a roundtable or a VC event almost every day, leaving little space for learning and shipping. The reality is, most of these events will be irrelevant, unless your target audience is attending them too.
Limited information, limited resources, limited runway — it’s important to prioritize what needs to be done and not get carried away by distractions.
On top of that, building a business helps to not only “play the long-term game”. It’s important to have a big vision and mission and to make your bets based on certain beliefs about the future, but that should not affect our short-term goals. Run your venture like a business — learn and build fast, ask for commitments and try to cut through the “startup” noise.
Takeaway for self: I have adopted a 6-week plan that I find extremely helpful now. I ask myself, “What is the desired outcome I want to be at in 6 weeks?” and write down the essential tasks to get there. I define a max threshold of 10% for tasks that may not be relevant for my 6-week goal, yet may be interesting in the future (attending a talk that can be inspiring, helping someone else brainstorm in a field I may be knowledgable about but not directly contributing to me at this moment). Being on your own means having 5x the discipline vs. working in an established team, and it helps me to have frameworks around my time distribution.
6. Last but not least: the people
Ultimately, startups are a risky thing to do and you want to make sure you are doing it with great people. In my case, I could not wait to get started and simply went ahead without having a dedicated co-founder or team. Was I afraid of being alone? Certainly, but the alternative was to sit around and wait for the perfect match, and I was too enthusiastic to start doing.
Eventually, when I had an early working product, I had someone join me. We were faster together, able to ship more, and reach new milestones together. It was good, but I certainly underestimated some obvious yellow flags that signalized early enough that this may not be the right partnership — in our case, I had more “skin in the game”, while my co-founder saw startup as one of the many options on the table. For me, there was only one option and I had no time or mind space to look left or right.
Takeaway for self: Talk about the problem you are solving with other people — they may get excited to help or even join you. Make sure people you work with are as invested in entrepreneurship as you are (if you want to be on equal terms). Listen to your mind and body— it’s a fine balance between being optimistic and listening to your gut feeling. Do not settle for less in choosing the people than who you believe is needed to get to PMF together. You have probably heard of the 50 co-founder questions — have hard conversations early enough. Ultimately, have fun when working together.
Wrapping things up
In the end, you can get all these things right and it still may not work out - there is a reason to why only 10% of all startups actually make it. But doing your best to actively disprove your beliefs and ask uncomfortable questions can be incredibly valuable - this is where true opportunity lies. Too many people are afraid to enter this field, but that is exactly where we should go.
As you can guess, the people decision has eventually led to a breakup and I am happy about the way things went — I just wish I interpreted these signals early enough and spared both of us some time. I kept working on Hemy regardless and was able get more traction and move forward.
But it wasn’t enough. I realized the very beliefs I had about this space and the future were no longer as clear — and the bet I was making was no longer a big reason for me to continue. I still have the passion for sales tech and think we can design much better tools for salespeople, but I didn’t feel like I was in the position to do best on their behalf at that given time.
It’s probably one of the toughest phases in a founder’s life. Was I being persistent and gritty by not giving up? Or blind even when there are so many obvious signals that I should change direction?
I have realized that my grit should be moved to a new direction — a space where I work on a tough problem, with a huge delta between the present and the desired outcome, surrounded by great people - folks who are self-reflected, curious and hungry to do something on behalf of many.
So, what now?
In the past months, I have been helping other ventures build up a growth and sales funnel, doing sales coaching, and learning about problems in new spaces from logistics to renewable energy to (again!) build something new. I have new ideas that I am exploring and based on my lessons, I am keeping myself accountable for actively doing the uncomfortable things.
Still, as a solo founder today, I certainly do not want to miss out on working with great people. At this point on my journey, people are the first choice and ideas are secondary. I am now opening myself to new long - term opportunities to join early-stage projects or find a co-founder first, and validate ideas together. Whether a VC-type or bootstrappable venture, whether it involves a product or (partially) service, whether it is still early or with some traction already - I am curious to discover what is out there.
So if you’re building something new or still ideating, looking for partners in crime and think I could potentially add value — feel free to reach out and let’s have a chat! You can reach me on LinkedIn.
Apart from that, I would like to thank you for reading this piece. Special thanks goes to everyone who was part of my journey at Hemy - users and supporters, advisors and early believers, and befriended startups and builders.
If you have any thoughts to add to my learnings, I would certainly love to hear from you too.
Keep building and stay hungry,
Mika