Achieving Product-Market Fit

Jan Koscelansky is the co-founder and CPO at Sudolabs. He began his career in strategy consulting at Accenture, focusing on digital transformation. Jan then moved to product management at OLX Group, where he managed digital products for a global marketplace with over 300 million monthly active users across more than 30 markets. At Sudolabs, he leads the product and design teams, combining rigorous validation processes and user-centered design to support clients in achieving product-market fit.

In your experience, what are the biggest risks founders should prioritize in the early stages of validating their product and idea?

In the beginning, many founders are scared about more visionary, more long-term things like, okay, am I going to get to 1 million users as I want it, as fast as I planned, or will my company become a unicorn? However, they should focus on risk mapping and understanding if their idea is just an idea or if there is potential. What are those risks? One is value risk or desirability risk - you can have a beautiful idea based on your needs and problems, but is there enough large market for such a problem? Are people willing to pay you if you solve this problem for them? The second part is usability. So the question here is, if you even find the valuable problem that users will be able to pay for, is the solution that you will bring them intuitive and easy to understand? Another one from the technical perspective is feasibility, which needs to be taken into account in the beginning. Can we build the solution with the given resources, with the given budget, with the given timeframe, or in general, if there is enough technology for it? Lastly, which stands on the shoulders of the founder more is business viability. So, can I find enough resources? Can I attract good talent? Can I attract partners? Can I raise funds on that? That's why we always try to work with founders where we see a so-called founder market fit, meaning that the founder should be already somehow well accepted on the market and understand the industry and not like have an idea and trying to explore a completely new domain, which can be a very significant blocker for this fourth risk.

Out of the risks you mentioned, which one do you see as the most common challenge for startups?

All of them are relevant. All of them should be checked. And it depends on the particular situation. What is important for the founders is to be the visionaries, right? The founders need to be able to sell their idea, sell it to their investors, and sell it to the people. And that's also tricky because if you believe your idea so strongly, you can forget about those potential risks. The solution is to split the roles with someone else, ideally a product manager, CPO, or CTO. As a founder, you should partner early enough with someone who will be more down-to-earth and able to complement your visionary thinking with more execution focus.

That's what we do with our clients in Sudolabs. That's where we can add the most value. So, we take their vision and start to dig in deeper, validate each risk, and build some prototypes because it's never so straightforward. You need to focus on your idea, but be able to change the path how to get there. As we've seen with almost every successful client or product we built, it was different from the product we started with. Throughout the journey, there were so many pivots. So be open-minded, be flexible, and count on this reality that it will change a lot. Remember all the risks, find somebody who can complement you, and focus on those risks.

How would you validate whether a product idea genuinely solves the target problem, and how do you ensure the solution is both time- and cost-efficient?

Initially, you should not focus on your solution because this is really fluid, and you may believe this is the best solution for you. But there need to be thousands or millions of other people who will also say the same sentence; this is a good solution to my problem. There is a good example with one of our clients that we were doing a discovery phase together, and they were trying to solve the problem of building data pipelines. I don't want to get into much of the technical details, but the problem was how to enable data engineers to build and manage their data pipelines. It's like a technical infrastructure for transferring and working with data. So, how do we build these data pipelines much more efficiently? Okay, perfect problem description. Clients approached us, of course, with a suggested solution. They wanted to build a low-code platform where the developers could just drag and drop these data pipelines and connect some data sources without the need to write code. What we often suggest is to pause, take a step back, and validate with the market. In this case, we were trying to understand if data engineers also felt that this problem of managing and maintaining data pipelines is so urgent for them. We successfully validated with any data engineer we talked to; yes, this is tedious work. Then we asked them about our suggested solution, and the result was not so positive. We discovered that data engineers felt the problem, as our clients suggested, but they wanted something other than a local no-code tool. They wanted pre-built templates or something that could help them manage and create the code, but they wanted to keep that code. The client was super happy because if they spent planned resources to develop such a tool and discovered that nobody wanted it, it would be a huge problem.

In Sudolabs, we try to release any product iteration in a maximum of 8 to 10 weeks. So, anything we want to build needs to be small enough to be developed within 8 to 10 weeks. If we estimate that the scope is larger and it would need more time, then it's a goal for product managers to de-scope it. They prioritize something out of the scope and ensure that something can be released to the market within 8 weeks, then collect the feedback and decide what to build next.

How do you decide when you’ve done enough validation to move forward with a product idea and avoid the trap of over-validating?

Well, you'll never have enough confidence, and waiting for such a moment is impossible. Also, it's impossible to just jump into the development with some assumptions. So, it's not about the length of the process but about the iterations in the process. One example is a client who talks about his idea with some potential clients for I don't know how many months. He was getting positive feedback because if you don't do it in a structured, even scientific way, you are just talking to some people who don't want to disappoint you or be rude. So they say, "Hey, it's a great idea. Go for it. " It's more like a friendly confirmation. What you need to do instead is move fast with the small iterations. Build some small prototype that can be tested so that you can see how it behaves, get some perception of it, get it back to the hands of those users, get the feedback, and then move again.

Validation is not just about discussions but also about moving in these small cycles. We always recommend to our founders not to be so perfectionist about their first product but to be able to go on the market with something scrappy, with something like 10% of their ideal state. But let's build it. Let's give a chance to the team to play with the solution. Let's give something to the hands of the users. And let's do it often, every month.

What metrics do you focus on to determine if you're moving closer to product-market fit or if adjustments are needed, especially as the product evolves?

What is nice about the product market fit is that you don't even need those metrics or a quantitative confirmation. Usually, when a startup gets the product market fit, they will know. They will know because suddenly the daily problems that you are solving have changed. Suddenly, you are facing an infrastructure limitation; you need more and more servers. You also need more service, customer service, and people to manage as a huge demand is coming for your product. But from the quantitative perspective, it's also possible to measure it.

“Product market fit is like this magical unicorn everybody is trying to catch.”

Usually, a good measure is, for example, the retention curve. So when you see user retention that is not declining much over time, As the users are coming in, they may be active in the first week or second week, and then it will drop down. If you have a product-market fit, it's somehow going to stabilize. Retention is extremely important for the technological product. So that's why, when we are building products for our clients, we are saying that, hey, let's not focus at all at the beginning, like how many downloads, how many visitors, but how to make the user experience that it's going to allow those users to come again. And that's exactly what you'll see in this retention curve. It's going to flat out and not decrease so down as in those situations when you don't have a product-market fit.

Are there any more specific metrics you’d recommend for early-stage founders to focus on?

Other than the retention curve, it is to have technical analytics instrumentation in the product, which is super easy nowadays. You have many various products. For example, we often use Amplitude in Sudolabs for our clients. Start measuring what's going on in your product. And you need to find some patterns there, usually in how different segments of your user base behave. As I said, the first one is retention, but another good one is to see the path throughout your product and where those main leakages are. And if you see that, okay, there is some touch point in your product, I don't know, a user needs to do something, try to talk to these users, try to get them on the interviews or maybe record their behaviors and understand what's going on there. Focus less on adding new and new features to your product. A better way to get to the product market fit is just improving and stabilizing what you already have, understanding if those users are seamlessly flowing in through your product. Only after you get that moment, add a new feature, add more complexity, and explore new markets or verticals.

What are some important lessons you've learned about building a product team, particularly when it comes to defining and supporting the role of product managers?

Well, of course, delegation is the major challenge for anybody who is building a team. So this is the main lesson learned. From the early moment, you should always have somebody with you who will help you do stuff and grow the team. My rule now is not to start any activity just by myself. I always have somebody with me who will help and learn, not to isolate any knowledge just with my role. Otherwise, it is much harder to delegate it to somebody new who is just jumping there at some point.

In Sudolabs, our product team is around 17 people - product managers, designers, and consultants. I think in general, not looking only at Sudolabs or at agencies, but regarding product, what is important to understand is that the role of a product manager or any product person in your team is not just to write tickets or to, I don't know, manage deadlines or to be some project manager or just to document your ideas as a founder and put it into the development process. A product manager's role is more about holding the responsibility for the business result of the end product. Product managers should have enough autonomy to basically take this vision and bring their own solution with the team together, as we said before, with an understanding of the user needs and everything. Being a product manager is a lot of business responsibility.

What key qualities make someone the right fit for a product manager role, and is a technical background essential?

If I can generalize this topic, I would distinguish two groups of product managers that can fit very different companies or situations. From my perspective, there is a huge difference between these early-stage product managers and product managers for scale-ups or large already mature products beyond the product market fit. In that phase, you need somebody who is more incremental, who is not just bringing new, huge ideas and changing the course, but who is more like just doing little tweaks, improving these decimal points in the conversion rates, doing small experiments, and it's much more about scalability. A completely different situation is for a product manager who has to build an early-stage product. There, those words like scalability or building robust things, it doesn't belong there at all. You need to be more of an explorer. You need to bring huge pivots to the market, and it's super hard to find a product manager who can cover these two things. So, if we are talking to readers who are an early-stage startup, you should also be searching for builders trying to get something from zero to one and getting this speed to the market. If you are somebody who already has a huge, mature organization, then the product manager should be working with the data more, doing a lot of quantitative research, experimenting, and making incremental changes in the product.

Product managers don't necessarily need an engineering background but must be technical. And what it means to be technical, from my perspective, is mainly about the passion for technology. If I talk to the engineer, I know how to talk with him. I know the words. I know what he's saying to me. If I see some architectural diagrams, they are familiar to me. Ideally, everybody should be close to technology as we build technology products, even if you are talking to designers, finance guys, or salespeople. If you are in the technology industry, you need to be technical.

Have these handpicked highlights sparked your curiosity? You won't want to miss the full conversation with Jan Koscelansky on our YouTube channel or your favorite platform. The episode dropped on May 14th, 2024.

If you need a ready-to-go & dedicated team of product managers, designers, and engineers, we are ready to help. Drop us a line at [email protected], and let’s turn your product idea into a successful product!