Product Management for Startups: Zero to One
Are you a startup or on your way to become a growth stage organization?
Are you wondering if and when you should add more Product Management processes? When is the best time to hire a proper Product Manager? What should his or her priorities be to set your company up for success?
In this article I am going to talk about companies that are in the phase of transformation between an early startup to a growth stage company and are trying to slowly introduce certain Product Management processes in their daily routine.
The focus is on startups and growth stage companies since those are the ones where Product Management processes often are either absent or recently introduced, which can lead to many challenges. I will share my own experience (I work as a Product Manager at the fast-growing startup Data Talks) and hopefully you can get some ideas and best-practice on how to create your own path towards building a proper and solid Product organization.
There are three types of organizations in today’s tech scene: Startups, growth-stage companies, and enterprises.
Startups are new product companies that are placing all of their efforts to identify and establish a product market fit. They do not typically have access to more than 25 engineers and it is very common that one person covers more than one role. Learning and moving quickly becomes crucial, while failing fast is a core value in the organization. Working at a startup can be an incredible experience, yet most likely, quite stressful and exhausting.
Growth stage companies have already succeeded in finding the product market fit. They are now in the phase of scaling up as an organization. What tends to happen at this stage is that engineers feel frustrated about not having the bigger picture. Why are they developing the features being asked for? It might not be clear to everyone how their work is contributing to the business goals communicated by the product manager and/or the executives. The technology infrastructure that was serving for the very first version of the product is not adequate enough, and perhaps, technical debt is more often mentioned by the engineers. Finally, the organization itself is changing. The teams are growing, new roles are being added, and the whole organization structured needs to be overseen. Leaders have to change roles and behaviors to adapt to their growing organization.
Enterprise companies are already established organizations, which succeeded in scaling up. Their challenge lies in having to ensure consistent product innovation. History reminds us of the big enterprises that vanished because they failed to do so. If enterprise companies fail to innovate, they will most likely enter a slow death. Nothing will happen overnight, but be sure that the end state is quite certain.
The Problem: Early Startup with no Product Manager Role
It is very common for early startups to not have a person fully focusing on the Product Management Role. That role is either being performed by one of the co-founders of the company or it is a shared responsibility among several people with managerial roles. This is fine as long as the company is a very early startup with just a handful of engineers in total. As soon as the company grows and a proper engineering organization starts to take place, by not having a Product manager you might face some, if not all, of the challenges below:
- There is not a single person to drive the Product development forward, thus time to market is usually quite long.
- Features in the roadmap are influenced a lot by the latest technology trends rather than focusing on the relevant problem to solve.
- Engineers are missing the full picture of why they are developing those features that they are working for months to ship. (That is actually a common problem, even with a Product Manager in place).
- Product Discovery process does not exist. This is one of the most important processes when it comes to evaluating if the product is valuable, usable and feasible to build. If Product Discovery is absent, the chances of spending months into a feature that will never be used, or even if used will never add value to the customer are extremely high.
Do those issues ring a bell? Then you need to create the Product Manager role and assign a person to it.
The Solution: Introduce Product Management processes early on.
Hiring an external person or assigning an existing one to become the Product Manager is the very first step to tackle the problems mentioned above. However, the Product Manager role itself cannot guarantee your success. This person needs to set up some important Product Management processes and the business should support him or her in setting up a Product organization.
Before we dive into the product management processes, the first thing I’d recommend you to do is read the book “INSPIRED: How to Create Tech Products Customers Love” by Marty Cagan. Now I’m going to share with you the key takeaways when it comes to what a Product Manager should focus on during the phase of transforming from a startup to a growth stage company.
Product Vision
The first thing that a Product Manager should look into is the Product Vision. The Product Vision describes the future your organization is trying to create. It’s purpose is to communicate to the teams why they are spending their time working for your company and what you are striving to achieve. As a Product Manager, you need to give a meaning to what they do on a daily basis.
Product Strategy
One of the most basic, yet crucial, things a Product Manager should learn is to say no. Not necessarily inside your organization, but saying no to the market itself. You got it totally wrong if you have the perception that you can please everybody at once. Then, you will certainly end up satisfying nobody. Product Strategy is really important when it comes to deciding what the market is you are trying to target. Who is the audience you want to target? Are they students, seniors, families, singles, or related to a certain profession? You will need to create different customer personas and rank them in order of importance. Geography is quite often a factor. Are you focusing on certain parts of the world? In case your customers are other businesses, what is the vertical market? (e.g. Utility, sports or retail organizations). The Product Manager, in collaboration with the business counterparts, should decide these. The goal here is simple: Target one market at a time!
Product Discovery
Product Discovery is the method of understanding if the product (or features) you are developing are satisfying the customer needs. A key part of Product Discovery is to provide evidence in regards to this and not base the decision on your gut feeling. In short, you want to make decisions based on real data, not guessing your way to the product roadmap. If you want to create a great product, you need to get your ideas evaluated by real customers and end-users as soon as possible in the process. Preferably, before you start building anything.
The purpose of Product Discovery is to address four critical risks:
- Will the customer buy this product and use it? What is its Business Value?
- Can the user figure out how to use the product? What is its Usability?
- Can the engineering team build the product? Is it Feasible?
- Does the solution work for the business? Is it Viable for your Business to maintain the Product you are developing?
Those are questions that your Product Manager should respond to with both qualitative and quantitative methods. We will go through Product Discovery in another article as it is a big and important subject to cover.
> Product Prototyping
One of the most important and critical Product Discovery processes your Product Organization should support is Prototyping. Prototyping helps you to answer some of the Product Discovery questions stated in the section above, without going too much into building, testing and deploying a product. There are a few types of Product Prototyping but I will recommend you to look into these three and feel free to combine them together.
- Feasibility Prototypes. These are prototypes written by your engineers to check if the product that you are trying to build is technically robust. Promising a Product without first assessing if you have the skillset and technology to build is never a noble thing to do.
- User Prototypes. These are usually distinguished into low-fidelity prototypes such as wireframes or even sketches on a paper, and high-fidelity prototypes such as simulations of the user interface you create. They are designed as such so that it is really hard for the end-user to tell if the product she sees is a prototype or a real implementation.
- Live Data Prototypes. These are prototypes of the product with real data instead of dummy data. We usually go into the misconception that testing our product with dummy data is the same as testing it with real data. But that is rarely the case. Prototypes using real customer data prove, in a more certain way, if the idea you have is really going to work.
> Customer Interviews
As soon as you create the prototypes, it is extremely important to set up customer interviews to share those with your existing customers. There are many different ways of conducting a customer interview. What I prefer are scenarios based interviews. In short, you write down a script about some scenarios that an end-user can perform in your application and see how the user tries to solve them without your assistance. You will be surprised about how much understanding you are going to gain about the usability of your Product. What seems perfectly clear to you as a team, might not be clear to a user and so on. In addition to the scenarios exercise, you can have a more abstract and free discussion with your customer at the end of the interview. This discussion will also give you a sense of who your customer is, what their maturity level is when it comes to your product, and if they are who you think they are. Do they have the problems you think they have? How have they been trying to solve these problems so far? And what will pull the trigger and make them to switch from what they did so far to what you propose to them?
The Product Manager should have a very active role during the customer interviews and you should make sure to make this a habit, if you would like to create a product that adds business value and is usable. You really do not want to spend weeks on developing features that nobody will buy or use.
Product Roadmap
Next thing you want to do after you have established your Product Strategy and started the Product Discovery process, is to scope the design, development, testing, and deployment of the features and add them to the Roadmap. And this is where the problem usually starts!
Even with the best of estimations and intentions, Product Roadmaps are meant to fail to a certain extent. Sometimes the customers are not really excited with your new idea or feature, and even if they seem to be they might not know how to use it. In addition, many times you make miscalculations in the feasibility assessment. A feature might take much more time and resources to develop than what you thought initially. Even if you develop and deploy a feature, you will probably know right away that the same feature will need quite a few iterations to reach the state you were visioning when you or your Product Manager started scoping it together with the UX designer and the Tech Lead.
> Outcome based Roadmap
Is your Management frustrated that the Roadmap timeline is not followed? Or are your engineers annoyed that the Product Manager asked them to follow an unrealistic Roadmap? We want to avoid coming to this place.
An alternative that I urge you to look into is Outcome based Roadmaps. By working with that method you will create the foundation for a goal-led rather than feature-led product team.
There is a great article regarding Outcome Based Roadmaps here and I advise you to go through it. The overall idea is that you need to move away from becoming a Feature Factory, where you ask your engineers to develop and deploy stuff that they do not even believe in or that they do not understand. Instead, focus on the problems, the ways to solve them, and what the expected outcome will be.
Outcome based roadmap is about deciding:
- What is the problem that the customer faces?
- Is this aligned with your company’s business goals? In the end, you are not obliged to solve all problems that your customers have.
- How can you measure if you achieved the Goal? What is the outcome for your customer?
- What are the different ways to solve the customer’s problem?
Now, discussing those ideas with the engineers is where you get them fully involved. Only if they fully understand the problem will they give you solution proposals. The solution proposal is the feature they are about to develop. It is not an easy task and of course ideas can be quite vague, the solutions limited, and you might not know where to start and how. This is completely normal. You will need some practice, but when you get into it, it will definitely help your product organization to transform from a Feature factory to an Outcome based one.
Conclusion
Those are a few of the Product Management processes you should start with as soon as you consider hiring a Product Manager to your growing startup. They are extremely important and make no mistake, you cannot succeed without them. Be also certain that it will take quite some time to establish these processes and introduce more, but even by employing some of them you will see more happy faces around you. In later articles we will talk about these in detail and how we are actually practicing them in reality.
