Every founder is a product manager, designer, and engineer, among many other things. The product is the company itself. The customers are the investors, employees, and partners. Building an app and building a company are two pretty similar things. The techniques, mental models, tricks, and hacks can be applied in both cases. So, founders and CEOs can be inspired by what the developers, product managers, and designers are doing. As the company grows, founders are removed from the primary software product. However, they always stay in the company, which they have to design and build continuously.
Not many early-stage startups have a dedicated product person. Usually, the team consists of a founder, a few developers, and maybe an operations/business person. So, the product manager role is shared among the founder, the lead engineer, and possibly others. That’s not necessarily bad. As long as the team is close to the customers and able to hold the product context in their heads, a PM could actually stand in the way and hinder the process in these early stages. You can get quite far with a common sense approach, but it helps to learn about the basics of product management, product design, and engineering craft.
Knowing more about that will elevate your common sense baseline and extend your runway. Not in terms of money, but in terms of competence and capabilities and how far you can take your company without a product manager and a product designer (not to mistake with a graphic designer). It will help you build a better and more successful product, app, service, system, or whatever you’re doing.
However, at some point, if the startup works well and grows, a dedicated product manager or CPO will join the company and take care of all the responsibilities that were initially shared. Knowing more about the craft will help you hire the right person. As a founder or CEO, you will start getting further and further away from the daily details and design of the product itself. At the same time, your job will shift to the company itself. That will become the thing you’re supposed to design, build and grow. Technically, that’s something you should work on from day one as well, but it’s understandably side-tracked until the organization gets reasonably big. So, all those skills you acquired while building the app in the early days will come in handy, and you can successfully apply many of those, even though we’re talking about the company, not an app. And even though the customers are not users of your app but rather employees of your organization, investors considering your startup, or business partners who want to cooperate.
Your employees will have high demands from you and expect a similar level of excellence to what they’re doing when building the app.
Product management, product design, and product engineering are all young disciplines, so there is no universally accepted best practice. There aren’t even many cohesive schools of thought you could compare and pick from when deciding how to approach the product-building process. At the same time, there are tons of types of products and services, and even among the digital products and apps that this text focuses on, the differences can be staggering. On one hand, it can be a B2C app with millions of users. On the other hand, it can be an enterprise, on-premise, mission-critical platform.
So, it’s impossible to provide universal advice that every startup would be able to absorb and apply. On the contrary, practices that a B2C app startup successfully does would be catastrophic when used by manufacturers of spaceship operating systems. It’s more up to you to critically judge what makes sense for you, your app, and your organization. And apply that. And what doesn’t make sense is the stuff you may happily ignore.
Plus, the stuff presented here isn’t an exhaustive overview of all the mental models and practices that could be found. Instead, it’s a curated and limited selection of stuff that I came across and successfully used in practice or that I personally like. Therefore, it’s inherently biased by my personal taste and by the products I’ve been building, mainly in Mews.
When you’re at the beginning of your career, it might be difficult to critically judge what makes sense for your product. E.g., when picking a development methodology, how do you decide which one to choose? One “meta-practice” that worked really well for me when selecting a new mental model or practice is the following: