At early-stage companies like Weaviate, teams are still small, so it’s often difficult to justify both a dedicated Product Manager and a formal engineering team lead. However, early-stage companies also set a high engineering tempo, so strategic product decisions can often only be made by someone with a strong technical background. That’s why in Weaviate case, a single person often takes the lead in both product and engineering decisions. This is not a compromise, it’s a strategic choice.
Combining both roles into one—we call it “Product Engineering”—is the best way we’ve found to develop and iterate new ideas, and to quickly get from a “lightbulb” moment to product-market fit.
Learning from both good—and bad—examples
Before co-founding Weaviate, I worked at companies with more traditional structures, in which product managers and engineers were different people, from different backgrounds, doing their own things. In some places, PMs and engineers fostered good communications, and made decisions together without regard for hierarchy or seniority. The barriers between those roles were lowered and the natural conflict that sometimes exists between business interests and engineering performance was healthy.
I also saw companies where product managers and engineers could not get out of each other’s way. This was especially a problem in companies where PMs could not understand use cases, because the users were, themselves, also engineers. (This, incidentally, is true here at Weaviate.) Likewise, engineers failed to think about the big picture while they scrambled to achieve arbitrary deadlines or create poorly conceived products. So, I knew what I wanted to achieve and what I wanted to avoid as Weaviate CTO.
Looking back on it, I was already sure that the best way to break down the product vs. engineering mindset was to encourage engineering to take on product decisions - at least at first. At the time, I didn’t have a name for such a position or realize that there were already examples of it being successfully combined in other enterprises. (See examples here and here.)
We define a good idea as one that’s intuitively convincing, backed by evidence, supported by a strong business case, and that fits our overall vision for Weaviate. You’ll note that the originator of the idea — whether it came from someone with a senior-sounding title — is not part of that definition.
However, collaboration and open communication are some of our core values, so as a team, we already see ourselves as all “in the same boat”. If Weaviate — and the company — are successful, we’ll all succeed. Having such a corporate culture may be essential if the Product Engineering approach is to succeed.
What does product engineering look like in practice?
The most important aspect of this role is that the engineer really sees the big picture. Every feature, every commit, and every line of code needs to advance a use case that’s consistent with the company’s business goals. Decisions must be made from the user’s perspective. This means, of course, that the engineer must understand the user’s needs and empathize with the user’s situation or problem. And it means that the engineer must be an excellent listener, because this is the foundation for the communications skills this approach requires.
Some (perhaps most) of the companies that choose to take this product engineering approach will still have a role identified as Product Manager. But that role also changes when the product engineering philosophy is applied.
Product managers need to involve engineers in day-to-day decisions. This requires a healthy level of trust and pragmatism on the part of PMs. One reason I feel strongly about this is that in my view, no manager should waste time on decisions that require only common sense. Similarly, engineers need freedom to handle edge cases on their own—even if they would traditionally be considered “product decisions”. This is not a case of responsibilities being stripped from PMs. Rather, it frees them up to focus on bigger decisions and strategic thinking.
This only works with mutual trust. Engineers need to trust the PMs’ vision. PMs need to trust that engineers understand and have bought into the vision, and will make decisions that advance it.
Challenges and long-term implications
People who can think and act like product engineers are rare, and they know it. So, naturally, they come with a higher price tag. If you plan to retain a distinct product manager position, that becomes harder to fill as well, because if common-sense decisions are no longer the responsibility of the PM, all that remains are big, bold decisions that have a long-term impact. But these challenges are offset by the fact as that sense of ownership increases, everyone feels more responsible for their work and cares more about the long-term health of the product and company; output and quality will improve.
Even if I’ve convinced you to operate without a dedicated product manager at the beginning, you may wonder what you’ll do when the team has grown, and the responsibilities are too much for one product engineer. At that point, you might hire a dedicated PM and double down on an engineering lead. Or, will you choose to hire an engineering-minded PM? Of course, that would be a challenging role to fill with an external hire, but by that point, you may be able to promote someone into such a role from within your ranks.
You’ll cross that bridge when you get to it, but if I’m right by that point, you will be committed to blurring - if not erasing - boundaries between PM and engineering roles.
Why product engineering is the best approach for a company like Weaviate
The most obvious advantage to merging the roles of product manager and engineer is that in a startup setting, the boundaries between roles are blurred anyway. It’s hard to justify hiring a separate product owner and tech lead when the whole team is three or four people! Making product decisions outside the team is wasteful in a different way; it makes the team dependent on some external person and risks creating a disconnect between engineers and users.
But a product engineer can fill both roles. They can align with a Head of Product or even the CEO on the long-term vision, while tackling day-to-day decisions inside the team. Other domain experts, such as UX designers need to be involved, too. This way, every other member of the engineering team benefits from having an actual decision-maker with them in the daily standup.
Just as important, the product engineering approach helps a startup to iterate fast, making mistakes while they’re still cheap and allowing the company to learn quickly.
Users tend to give very poor feedback when a PM pitches them an idea. But users give excellent feedback when presented with a prototype. The product-engineering approach, which lends itself to rapid prototyping, gets the startup to that point of first meaningful feedback as quickly as possible. That, in turn, enables Weaviate to deliver a steady stream of high-quality software.
As CTO, that warms my heart.
Stay connected
Thank you so much for reading! If you would like to talk to us more about this topic, please connect with us:
- Community forum
- GitHub Don’t forget to give us a ⭐️!
- Slack
- X (Twitter)