Seven Steps to Enlightenment for Early-Stage Product Teams
This post is part one of "the DNA of Solu", an article series about our company's principles. The first part is about product management – how we think about and do it at Solu.
Product management is often neglected by startups. This post will help you identify warning signs of absent product management and show the steps how early-stage founders can improve clarity, simplicity and focus.
1. You need product management from day 0.
The first mistake is omitting product management completely in the spirit of “keeping it lean”.
In reality, product decisions won’t go anywhere even if they're swept under the rug. They are lurking behind the corner, waiting for every opportunity to disrupt your developers’ and designers’ workflow.
Do this for a year and wake up to a bloated codebase, unshipped design ideas, and a burnt out team.
Good product management creates clarity, which allows people to focus on problem-solving, minimizes context switching, and buffers from unfiltered impulses. This will improve both your direction and speed of progress.
Be explicit and upfront with your decisions.
2. Focus on a problem before working on a solution.
Are you doing systematic product discovery or simply following your vision? While the latter can work, it’s like trying to get rich by playing the lottery.
Customer work is hard when you’re starting out. It’s much more comfortable to start theory-crafting and building what you think the customers might need. This leads to unique, technologically superior products, that are at least category-defining to you. The only problem is that nobody uses them.
The stubborn will hire a Head of Sales, pour more money into marketing, and avoid responsibility by claiming “the market isn’t ready yet“. The enlightened will head out the door to have a reality check.
Solve a real customer’s real problem. Distinguish your thoughts from facts.
3. Learn the magic word.
When you have some product management in place – a vision, an actionable roadmap, and a team, the temptation to add features starts to rise. Always keep shipping! Let’s outdo our competitors!
Without the magic word, a new monster called scope creep enters. Scope creep starts with innocent remarks, such as “how long would it take” or “the customer asked…“. As anyone who's been in software knows, small things might be small at first, but add a forever burden to maintenance. Remind yourself of the cost–benefit assessment: if your users get a 1% benefit, and your codebase is 5% harder to maintain, is it worth it?
What is the magic word? You've probably guessed it, but I'll let Jessie J do the interpretation:
Focus on the few things that matter.
4. Consistency beats crunching.
When your team is on a deadline, it’s tempting to have everyone work around the clock to deliver the product. Not only is it unsustainable, but it also leads to mistakes, bugs, and technical debt.
On the other hand, extending deadlines for no reason is also a red flag. This undermines the team’s morale, opens the door for fluid requirements, and makes you chase a moving target.
Product sprints are like marathons. You can’t sprint the whole marathon, but you can keep a steady pace with a bit of planning. Consistency comes from having clear definitions, realistic timelines, and frequent check-ins to remove blockers.
I see no reason to rewrite what’s been said elsewhere about the perils of crunching. But if you find yourself constantly struggling to meet deadlines, cutting corners, and staying late at work, it’s time to wake up. Don't get me wrong – speed is important. Hard work is irreplaceable. But it takes a special kind of moron to try to win a marathon by sprinting.
Get faster by condensing the scope, not the deadline.
5. Effort is everything.
Using time and effort to build products has a reputation of wastefulness – after all, we live in the era of 80/20, MVPs, and low-cost experiments. Speed is the holy grail of modern product teams.
That is, until you start adopting a customer-focused viewpoint. Why would anyone want something “minimum viable”? Why would anyone care about your company if quality is an afterthought?
By building less, you earn the freedom to build better. Create a special product, and your marketing problems are solved. Being a maximalist in the right place gets you ahead of the competition. Knowing where to aim for greatness is actually the core of product strategy.
Learn the things your customers care about and double down on them.
6. People are not resources.
The reductionist view of humans as resources is still prevalent in tech teams. We let our roadmap dictate what kind of "resources" are needed in the team, as if developers were interchangeable machines with a fixed daily output and a life goal of maximizing submitted pull requests.
When you stop thinking of humans as perpetual motion machines, you will realize that:
- Output will naturally fluctuate from day to day
- People have unique strengths, weaknesses and motivations, which aren’t always visible
- Team productivity and individual productivity are not the same thing
- Team dynamics dictate outcomes more than the team's talent or experience
- Adding more people will not increase output in the same proportion
It’s more helpful to think of your team as a garden – give them the conditions for growth, and help keep the weeds and parasites out. Throw out Taylorian management mindsets, which will only hinder you.
Stop thinking of people as robots. Accept that this is not a tradeoff; it’s your greatest asset.
7. Efficiency is useless without focus.
All systems are limited by one bottleneck. Improving things that are not the bottleneck will have no benefit to the system’s performance.
Few people understand this phenomenon well, so let me say it again:
If you don't address the bottleneck, your work will not improve the system’s performance.
Improving non-bottleneck areas is called Efficiencies Syndrome, and the concept is an operations management staple in traditional manufacturing industries. Due to the nature of software, bottlenecks are often invisible, leading to lost opportunities for focus and prioritization.
Most teams will have a long backlog of ideas for new features, refactoring, and re-designing old code. Are you doing things that really limit your growth? Only by understanding your system’s limitations well are you able to cross the output-outcome gap.
Define why you’re doing things. Make hypotheses and measure the outcomes. Teach everyone on the team to think in systems.
Did this post resonate with you? Are you looking for a team where product leadership is not an afterthought?
If you liked this post, you will likely find Solu a great place to work.
We're hiring – take a look at our open jobs. Or shoot me a message on LinkedIn and let's have a chat!
