Beyond Logo

author image blog beyond

Written by Alexander Hipp


article image beyond blog

The Struggle of Going From Product Manager to Startup Founder

I struggled a lot with my role at a startup in the first weeks of starting Beyond. I had to unlearn a lot and create new behaviors. Here is why.

For the last 7 years, I have worked in several teams with different stakeholders on fundamentally different topics and products, from recommendation engines over mobile apps to freemium subscription features. Always in Product Management and always in larger corporations with at least 1500 people.

Starting a product-led company as someone with product management experience has a lot of advantages. I have a clear idea of how this company can evolve in the following years and how we want to work towards our vision. But creating a product and company from scratch also requires an entirely different mindset and skills. Building a new product compared to working in a company that has reached Product-market fit and has happy customers is fundamentally different.

These are the areas where I intentionally had to replace the product manager way with the startup way.

Being responsible for the product 

Normally a Product Manager, Head of Product or even director is accountable for a piece of the product. A feature set, a user journey, or an end-to-end experience. When building a product from scratch, you are responsible for the whole thing. End-to-end. You have to think of acquisition, activation, retention, growth, and everything around it. This was super hard to prioritize for me in the beginning. There is so much that we can and should build. Setting a clear focus and expectation every day on what you want to spend time on really helps to not feel completely overwhelmed. Not every little bug or edge case needs to be fixed. Just focus on the significant changes that really generate an outcome.

Doing things that don't scale

Utterly contrary to focusing on the big outcome-generating things, as a startup founder, I ended up a lot of times doing things that don't scale. Preparing an email campaign for 50 people feels like a total waste of time in the beginning. But that's how you start. Maybe 5 out of the 50 people are going to become superusers that accelerate your growth. What helped us a lot here is to see every action, every campaign, and every release as an experiment. Does it have a clear goal? Did it generate an outcome? If yes, repeat, improve and iterate until you have a solution that might scale. If no, stop it or improve it.

Improving a product to building a product

I would argue that most product managers at mid-sized and big tech companies are focused on optimizing a metric rather than creating new products and features. There is no problem with that; it's what they are hired for in the end. In a startup you are responsible for building a totally new product. You can use some techniques and frameworks but most of them rely on having user data. So getting traction is a huge topic and at least equally important as building the product. A rule of thumb here that helped us a lot: 50% making the product and 50% working on traction. Even if the product is far from great, show it to people and let them use it. We learned a lot from users signing up to Beyond and giving us feedback. We can incorporate this into the subsequent versions and make a better product. In startups, it's all about reducing risks, not about building shiny features that no one is using.

Learn to deal with tiny numbers

One of the biggest problems of my transition from a bigger company to building a startup is the number of active users of the product. I was used to talking about millions of people doing X. Experiments were conclusive in no time. Nowadays, I probably know many of our users personally. I had to change my toolset of doing user research and generating learnings from usage numbers quite a lot. From a lot of quantitative testing to almost 100% qualitative testing. A single user voice has a much higher weight if there are fewer users than thousands of users saying something when there are millions of daily active users. It's motivating but equally shocking to get personal messages from users who miss features or praise your work. Therefore it is essential to focus on your JTBD and vision and only adapt them if you see feedback patterns rather than individual feedback.

Reaching Product-market fit vs. maintaining it.

This has been probably the most significant difference and the hardest unlearning for me. There is no proof that the product you are currently building is something people want. Suppose you work at a company that has reached PMF before. In that case, the users get value, come back, and tell others about your product. Otherwise, the company would not have survived until now. In a startup, you don't have this security. Every decision you take can make or break the whole thing. Spending too much time on a solution that does not work is wasted time and can mean the end for the young company. We are well aware of this and therefore try to always stay open for product changes and pivots. We build features to create a specific outcome; if the feature doesn't deliver it, we iterate. Stay consistent within your vision, mission, and the problem you are solving but flexible on the solutions and how you fulfill the user's need.

Embracing the struggle

Everyone who worked with me before knows that I love structure. Workshops were always structured and planned to the minute to make sure we create the desired output. I'm a very visual person. Combined with structure, this should give my teams always the feeling of security, direction, and meaning. How does our current work fit into the bigger picture? Why are we doing X instead of Y? These questions I rarely heard because I tried to pro-actively support my teams and stakeholders with the information. Working at a startup is different. You don't get a price for excellent overviews and lists. There is no bigger team to align or convince. Decisions are based on what brings the most significant value now, and strategy can be reverted from one day to the other. What helped us embrace this chaos but always stay focused is organizing our work in 4-6 week milestones. Everything we are doing in this period is supporting the bigger goal. How we are doing it and what it requires is entirely up to the situation. Not every experiment or feature needs to be written in code or is supposed to survive beyond the 6 weeks milestone. If we reach the milestone, it served its purpose.

The founding team is everything you have

Leaving the the safety of working at a mid-sized post-PMF tech company showed me clearly how much value there is in having more people working together as a team. Designers, User Researchers, Developers, Marketers, and many more were always accessible and supportive. As a Product Manager, you usually sit in the middle between all of them. You need to make sure that they build the best possible product for the users while also generating value for the company. Even if you are not their boss, you have to manage the relationships with every one of them. Form a team that builds a world-class product. In a startup with two people, it's different. Together with your partner in crime, you validate the problem, design a potential solution, build it, and market it to your target audience. It's a two-person show. If you are not doing the work, nobody does. It's super important to only spend time on the important things.

Even if startup life is super hard and I had to relearn many things, it's the most rewarding thing I have ever done so far in my working life. Building something from scratch that people find valuable and use daily is very rewarding and motivating. Thanks to Shane for being the best possible partner in crime on this journey.

Join our waiting list

Curate and discover the best content on Beyond.
We're inviting new users every day.

Beyond on