For product owners with no room to breathe
You can never rely on your team delivering without you.
Every usable result costs you time and closeness to the team. In the end too little of either is left for the things that actually matter.
Book an intro callNot a sales call. If it does not fit, I will say so as plainly as you would.
Does this sound familiar?
- Sprint after sprint the team looks productive. At the end of the quarter the goals that really matter are no closer.
- You explain the same requirement for the third time — and still do not get what you actually need.
- In the daily scrum it is all "on track". Ten minutes later a stakeholder asks you for the release date and you have no answer.
What changes
How do you manage that?
Six things shift when your team prioritises differently — measurably, and noticeably day to day.
- Estimation — you finally estimate the thing you actually meant to estimate.
- Velocity — it becomes reliable instead of flattering.
- Bugs after release — fewer of them, because the team understands what it is building.
- Support tickets — they drop, because less gets built past the users.
- Refactoring effort — it falls, because there is less to correct.
- Team turnover — good developers would rather stay.
Developers understand more deeply what they are actually building — which matters now more than ever, since AI tools otherwise push that effect further in the wrong direction. The working day gets less dry and less tiring, and good developers would rather stay, even without an enormous raise.
Up to now you have essentially been estimating your own time — even when you thought you were estimating complexity. No wonder you are regularly wrong: Nobel laureate Daniel Kahneman documented exactly this as the planning fallacy. So we have to estimate differently.
Why I built this
- In large corporate projects I have watched too little empathy for users turn into bugs and sprawling refactoring.
- I have seen how much time endless correcting, patching and laborious instructions cost when developers do not understand what you really want.
- I was in a team with unhappy developers myself and suffered through the turnover that came out of it — until I left.
How the coaching works
Eight weeks, with your real team
-
1
Kick-off in FlightRoom
It opens with a relaxed kick-off meeting run as a team event called FlightRoom — which already reveals a great deal about your team.
-
2
Eight weeks alongside you
For eight weeks I work with you personally. You get supporting videos explaining the essentials — on your own schedule, at your own pace.
-
3
Regular coaching calls
Plus regular coaching calls where you ask every question you have. We work hands-on, directly with your real team.
Do be patient — change takes time.
One requirement: You should already have experience with user stories or job stories — most teams do. Write to me if you do not.
Want a look first? I have made one of the coaching videos public so you can see how I work and what to expect.
Voices
What others say
"Plenty of supposedly innovative ideas are purely cosmetic — as a certified product owner I have seen a great deal of nonsense."
"As a business owner I am now even more interested in setting things up so that a development team works without me."
"It changes real decisions inside the sprint — not just the conversation about them."
What stays the same
What changes is not the principles agile teams work by, but the way prioritising happens. Not a new framework built from scratch — a changed practice inside the existing principles.
This has nothing to do with LEGO Serious Play or the usual meeting icebreakers. It changes real decisions inside the sprint — not just the conversation about them.
Where this came from
It started with my own team, because I had exactly these problems. As a business owner I wanted to take six weeks away with my family and did not dare. So I started experimenting.
And then I learned like mad and experimented some more — until it turned into something I genuinely enjoy selling.
If I throw that overboard, the method degrades into a commodity, applied as half-heartedly in practice as Scrum so often is. That would do everyone involved more harm than good.
With this method you can end up with a team worth acquiring for the team alone — an acqui-hire. I know, because that is exactly why my team now sits with a former client.
Next step
You want results that count on your CV.
The raw material for that is what your team delivers — it decides what you can make of it. Results do not appear overnight, so the earlier you start, the better.
Book an intro callNot a sales call. If it does not fit afterwards, I will say so as plainly as you would.