Product Management lessons from an Early Stage SaaS Startup

I love reading about product management. But so far I haven’t found a lot of advice on managing product for early-stage companies like mine. The core ideas of The Lean Startup & Agile Methodologies still apply, but there are several things that a product management course, book or article will not teach you that are relevant for very early-stage startups that are trying to achieve Product Market Fit.

I have come to many realisations while building my own early-stage startup and I’ll try to share these lessons in a concise way.

Deciding what you’re going to build is hard

Trying to satisfy your users is not an easy task for an early-stage startup. But it also never gets easier, you just have more user feedback & tools at your disposal as you grow. Having more feedback or data, doesn’t guarantee easier answers though, as it allows many options to pop up and you still have to sort through everything. This may sound generic or cliche, but if you care about your users and are passionate about the problem you’re solving, then a lot of times you need to follow your gut.

Who are you going to listen to?

As an entrepreneur, you have and should have a lot of people involved in your journey. This could be mentors from your local accelerator, other entrepreneurs, your co-founders, your early users or anyone else whose opinion you take seriously.

When it comes to functions where you lack experience and you have an experienced person giving you advice (e.g. sales) then it makes a lot of sense to listen to that person. But when it comes to the direction of your product, which is aimed at achieving Product Market Fit, you shouldn’t listen to everyone no matter how smart or knowledgeable they are.

As an entrepreneur, your goal should be to know the market and understand the problem that you’re trying to solve better than anyone else. This means that all new information should be processed by yourself and your team and assess whether or not it fits the direction that you have set for your product. The most important source of information and insights will be your users. But not all of your users.

There are 2 important types of users that we need to distinguish:

• I love your product and I’ve bought a subscription (or whatever buying-in means in your case)
• I would buy it if XYZ

Why am I making this distinction between let’s say actual buyers and customers who would buy based on a condition?

It is simple: when you’re building a new and unique solution, you’re depending on early adopters. There are a lot of people out there, who no matter how good your product is won’t buy unless they’re sure it’s not a risk. And in order to estimate the risk, they rely on other people who were involved in the product earlier.

Something that happens quite often in our SaaS startup is that we have customers who request 1–2 final things that they expect from our product before signing. Those are usually minor requests that can typically be built in a matter of days. So it’s quite easy for us to just decide to build them and hope for the best in order to make those early users happy and convert them.

The sad truth though is that when you’re building something for trial users hoping they will convert because of this new thing you’re building there’s a discrepancy between your commitment and theirs. If you build this new feature, you don’t have the option of taking back the lost time while the other person still has the option of not buying from you.

Depending on the deal size, features like this should be put in writing when signing a contract with the customer or you should clearly communicate that feature requests from paying customers are typically prioritized.

So you should focus on and listen to early adopters. People who are bought into your product, who are actively using it and loving it. Do not listen to would-be buyers. Would-be buyers will end up not buying even if you implement all the requirements that you discussed. So focus on offering a great experience for the early adopters who are bought in and love your product. Find more people like them and make their success with your product your mission.

Balance the important vs the urgent

Whenever a customer asks for something new, my initial thought is to jump in and create what they’re requesting. This might be due to loyalty to our early customers, or due to feeling a sense of obligation towards people who are paying money to use your product. But jumping in and immediately building what your users are requesting is a slippery slope and here are some reasons why:

• Your users may think they really need something, and after you build it they end up not using it at all.
• Customers are more patient than you think. From my experience so far, customers are just as impressed when the feature they requested appears 2 days, 2 weeks or 2 months later. It’s about listening to feedback, not about letting customers run your product roadmap.
• More features = more maintenance, more maintenance = less time for new features (We’ll get back into this in a bit)

Taking into account customer feedback is essential for building great software products. But your customers should not own the product roadmap; you the founder should own the product roadmap.

Each feature you put out will have an effect much later

As a founder or early-stage employee at a tech startup, a lot of times you feel in control of your destiny because you can quickly roll out changes and new features. And it’s true, you can be very agile and produce changes.

But here’s the thing, shipping a new feature doesn’t mean that the impact is immediate. Of course fixing a serious bug has an almost immediate effect. But rarely does a new feature produce the desirable outcome immediately.

For example, your users may first need to be trained or get used to a new feature before it becomes a success. Or users may spam a new feature on its release day, but never touch it again. On the first day you think it’s a success, but then you realise it was just something shiny the caught the attention of your users.

The lesson here is to have a 1–2 month process of:

• Setting up expectations beforehand (more conversions? less churn? which kpi or goal?)
• Rolling out the feature
• Notifying your users through newsletter and if needed educating them
• Gradually measuring the results overtime
• After a month or two (or more depending on the scope) you can see if it produced the result you expected

The goal is to minimise the risk of getting overexcited about something that ends up not working, or being disappointed early on about something that does end up working in your favor.

More features = more maintenance

I have to say this again & again because a lot of times as a founder you think you’re invincible and you can do everything. You can roll this feature out, and the other feature as well and soon enough you have a long list of TODOs that looks endless. I believe that having a long list of TODOs or an endless backlog is inevitable and this problem will never be solved. Why do I think that? Well the simple truth is that products can always be better, and you as the founder can think of infinite things where your product is not as good as you’d like.

But here’s a big risk in the early stages of creating your product: feature creep. Feature creep is a dangerous monster in products that are released in big chunks like for example videogames. But it’s still a bad idea even if your product is shipped in a lean and iterative way.

Creating new features is typically more exciting than perfecting your core offering and tweaking things you’ve seen a thousand times. But the risk of adding many new features is that you will have to maintain them and as a result, you can spend less time on perfecting your core features and less time on creating new features.

Choose what to build carefully and don’t be overconfident in your ability to build everything. I am sure you and your team can build the features, but don’t forget to account for maintenance.

Own the product roadmap

The product roadmap is your map to product success(or failure). I’ll define product success in a simple way so that I can analyse it.

I would define product success as: a product that achieves its own goals in terms of usage and product KPIs but also contributes to the the overarching business goals.

A perfect product roadmap would contain the exact plan on how to reach your business goals through developing new features. But there are many senisble limitations:

Uncertainty: It’s hard or impossible to know exactly what users want and deliver it in a perfect way. That’s why you have assumptions, educated guesses and (user) research. But even then, you can’t be sure about what to build or how to build it.

Limited Resources: As I stated before, you can find unlimited ways to make your product better. But your resources in the beginning may just be yourself, or a small engineering team. So of course you can’t build and test everything.

Time: It takes time to build, deliver and test new features to find out if they contribute to your success.

Users: Succeeding but also measuring success, depends on having the right user base. Having a large user base also allows you to conduct experiments, A/B test new features and get feedback faster.

Your product roadmap has many influences as well:

Yourself (& your team): As an early stage startup, your co-founders and yourself will create most of the original product roadmap.

Mentors: If you’re part of an accelerator or take part in entrepreneurial events, then it’s likely that you know experienced entrepreneurs and experts in certain fields who will gladly share their opinions.

Early adopters: Your first users will give you feedback and request new things.

Non-buyers: People who claim to like your product, but don’t produce revenue. (Expired trial users, clients that you can’t yet serve)

The product roadmap is very dynamic, and of course it should be. If you start with a large document of requirements like a waterfall project, you’re not very likely to succeed (I won’t expand, but books like the Lean Startup or Scrum explain why).

In the end it’s you, who owns the roadmap. Your early adopters help shape it. Your mentors can help you figure out things. But you should be the final judge of what has to be added. You have to protect your roadmap from being unfocused. You own the roadmap, not your customers.

Have a consisent flow & output

Earlier in the article I pointed out that the result of adding new things to your product are not apparent immediately. In this section I propose how you should structure your work and what’s a realistic process that you can expect.

You may intuitively think that adding a new feature that looks exciting will equal success. Or that once you’re at a specific point product-wise, you will be succesful. But the sad truth is that success in startups is hard to pinpoint. Because in 99% of cases, there’s no single event or decision that made a product successful. It’s about sticking to a good process, following user feedback closely and delivering steady improvements.

So what should your goal be?

It should be to produce a steady flow of changes. The things you can control are limited. You can decide what to build, how it’s going to look and then start working on delivering.

Most times, delivering a feature 1 day earlier or 5 days later won’t change your long-term outcome. Since you’re a company that’s trying to build the right features in order to achieve Product Market Fit, your best option is to consistently produce changes and then track the results.

That should be your goal. There’s never a finished product, so try to avoid feature creep, listen to your users and have a consistent output of features.

This consistent output of features should lead to 2 results:

• Your product is now better because of the new feature
• Or you know something new! (The feature failed, or you learned something about your users)

I hope these lessons from my journey are helpful.