8 operating principles that beat any process and framework
Piotr Kaca?a ??
CTO / Board / Advisor ? I help companies building great product engineering teams
Most companies I work with spend a massive amount of time on processes. Sometimes, it feels almost religious.
I often hear questions like: How do we build a good roadmap process? How should discovery be done? How do we measure software delivery? Why are we so slow?
These aren’t bad questions, but in most cases, they don’t touch the root of the problem.
The problem with processes
Processes are easy to write down, measure, and optimize. They give a sense of control, which many leaders hunger for. Processes can help less experienced people keep up with the organization. But here’s the problem—they also slow down your top performers.
Think of processes like a lifeboat—they keep those who can’t swim from drowning but also hold back those who are ready to fly.
Processes can kill creative thinking. They grow out of control, especially as the company scales. Processes create bureaucratic structures.
And that’s a fast track to losing the speed you had as an agile startup. And that’s the number one offender when it comes to good people leaving your company - because they’re being slowed. That’s not how you build great products.
Let’s use agile as an example. You’re not agile if you’re adopting process frameworks like Scrum or, worse yet, SAFE. You can be agile (in the word’s true meaning) if you follow the principles stated by the Agile Manifesto. These were created before those frameworks.
What if you already have too much process?
A few suggestions:
Examples of operating principles
Operating principles are not just cringy hashtags you print and place on your walls for people to smirk about when you’re not in the room. It’s a list of guides that tell the team how to do their job and what to prioritize.
What operating principles should good product organizations have? Here are a few to inspire you:
Start with the problem, not with features.
Forget about new features for a moment. The main question should always be: Which user problem from our list do we want to solve? For each problem, there are multiple solutions. Then, start thinking about the features.
PS: An excellent framework to force you into this mindset is the Opportunity Solution Tree.
Think big, work small.
Have a vision for where you want to be in a few years. Break that down into strategies to get you there. Then, plan specific projects to move the metrics you care about.
This is your roadmap—strategy-driven, vision-based, cause-and-effect. You can read more about it here.
Ship fast, ship early, ship often.
Stop holding onto things until they’re perfect. Deliver features quickly, often, and early. Measure, gather feedback, and iterate.
Remember the Pareto principle—80% of features won’t succeed. Find the successful 20% as quickly as possible. Use prototypes before you put a single line of code.
领英推荐
Outcomes > outputs.
What counts in the end isn’t how many features you release but the results you achieve. Does your product solve your customers’ real problems? Are your customers happy?
These are the main reasons you should be happy about, not that you’ve shipped something (that nobody uses).
Trust > control.
Stop micromanaging. Teach people to think like you, give them context (for example, using Strategic Pyramid), be present, care for them, and help them from the backseat. Delegating and trusting multiply the talent.
This fosters resilient, motivated teams that can innovate, bringing more value to the company. Plus, you’ll stop being the bottleneck.
Innovation > predictability.
Predictability kills innovation. Choose a side. If you want innovation, stop obsessing over deadlines, give your team some breathing room, and yes, stop obsessing over processes.
Learning > failure.
Foster a culture of experimentation. A “failed” feature isn’t a failure if you’ve learned something and you can apply this learning in the future.
Don’t fear mistakes. Don’t penalize mistakes too much. Otherwise, your team will stick to safe bets, and safe bets rarely make first-page news.
Data > ego.
I believe in leaders’ intuition. But remember, you’re human, with biases and habits. Data are facts. Data should guide your decisions no matter how attached you are to your ideas. Trust your gut, but don’t rely on it too much.
How to start?
Intrigued how to implement your own list of operating principles?
Conclusion
If you live by these principles, you don’t need any specific process or framework to build products loved by millions worldwide. If you live by these principles, you should have a good strategy, constant customer contact, frequent deliveries, and a motivated, impact-driven team.
Instead of creating processes that force your team to fill out another spreadsheet they don’t understand why, guide them using operating principles. Next time, they may know why filling that pesky spreadsheet is important.
Operating principles become your DNA, your true foundation. And THEN, you can start figuring out where you need the process and where the principle is enough.
Good luck!
Data and Technology | Financial Crime, Sanctions, AML & KYC SME | Harvard Business Review Advisory Council member
3 个月Leading and demonstrating the guiding principles to create the culture you want is essential. The one area, I would change here (Trust > control) is to balance the amount of micromanagement required (control) as needed with an aim to minimise it and trust your people. Three example areas, where I've found it may be necessary is: Quality Control, Crisis Management, Training and Development. Exceptionally junior staff (fresh graduates) may benefit from micromanagement with training and development into their roles. Once they have been trained, supervised for a few cycles - then let go of the reins.
Chief Digital Officer. I work with People and harness Digital, Data & AI to enable a step change in results
3 个月Very helpful Piotr Kaca?a ?? I am a passionate anti-process guy. As you say they automate things from the perspective of the least capable rather than amplifying the most capable and as a result usually result in poor performance