Discovery / workshops
What do we know? What are we assuming? What problem are we solving?
Product leadership · Lottoland
A team is only as good as its weakest member.
I've always believed product leadership isn't just about improving the product. It's about improving the people and teams building it.
At Lottoland, that meant spending time helping Product Managers, Product Owners and their teams build stronger product habits — from how we framed problems and wrote stories to how we prioritised work, ran ceremonies and worked with stakeholders.
The goal wasn't to turn everyone into the same Product Manager.
It was to give people the tools, context and confidence to contribute at a higher level.
01 · The belief
Raise the floor.
The whole team gets better.
A strong product team can't depend on one or two people knowing what good looks like.
If one person doesn't have the context, confidence or product skills to make good decisions, that affects everyone around them.
For me, that's part of the Product Lead's job.
Not to become the person with all the answers.
To help more people make better decisions without needing me in the room.
02 · The problem
Strong individuals don't automatically make a strong product team.
The teams were capable and delivery was happening.
But like most growing product organisations, the quality of product practice wasn't always consistent.
Sometimes work arrived as a solution before the problem had been properly understood. User stories could become delivery instructions rather than conversations. Priorities weren't always clear. And stakeholder requests could quickly become roadmap commitments.
None of those things needed another layer of process.
Better habits, not more process.
03 · Start with the problem
Before writing the ticket, understand the journey.
One of the biggest shifts I encouraged was moving conversations away from:
“What ticket do we need?”
towards:
“What are we actually trying to change for the customer?”
We used tools like user story mapping, journey mapping and problem framing to understand the experience before breaking it down into delivery.
Problem↓Journey↓Outcome↓Stories↓Delivery
04 · Ceremonies
If a meeting doesn't help us make a better decision, why are we having it?
I didn't want ceremonies to exist because Scrum said they should.
Each one needed a clear job.
Refinement
Do we understand the problem well enough to build it?
Sprint planning
Are we spending capacity on the things that matter most?
Reviews
What did we learn, not just what did we ship?
Retrospectives
What should change about the way we work?
05 · Prioritisation
The framework matters less than making the reasoning visible.
We used prioritisation techniques where they helped — impact versus effort, value versus complexity, MoSCoW and other lightweight models.
But I never wanted the team debating which framework was technically “right”.
The point was to make the decision visible.
Why this?Why now?What are we not doing?What would change our mind?
06 · Stakeholders
Stakeholders shouldn't have to guess why something isn't on the roadmap.
A lot of stakeholder frustration comes from missing context.
If someone only sees the final roadmap, it's easy to interpret “not now” as “Product doesn't care”.
So I tried to make the thinking behind decisions much more visible — the customer problem, the evidence, the constraints, the capacity and the trade-offs.
From
“Why aren't you doing my thing?”
To“Given what we know, is this still the right priority?”
07 · Coaching
Coach the decision. Don't just give the answer.
When a Product Manager or Product Owner came to me with a problem, I tried not to immediately solve it for them.
I'd normally start with: “What do you think we should do?”
And then: “Why?”
That gave us something much more useful to talk about: the evidence, the assumptions, the trade-offs, and whether the decision actually supported the outcome we were trying to create.
The point wasn't to make people dependent on my judgement.
It was to help them build confidence in their own.
08 · What changed
The biggest change was ownership.
The shift wasn't perfect or complete. It showed up in the way people approached the work.
Clearer problems
Teams increasingly started with the customer problem rather than the requested solution.
Better stories
User stories became conversations about behaviour and outcomes rather than specifications handed to Engineering.
Stronger prioritisation
Trade-offs became more explicit and easier to explain.
Better refinement
Teams came into refinement with more context and fewer unresolved product questions.
More ownership
Product Managers and Product Owners became more confident making decisions without escalation.
Better stakeholder conversations
Roadmap decisions became easier to explain because the reasoning was visible.
09 · The real test
Product maturity is what happens when I'm not in the room.
The real test wasn't whether people could use a story map or run a refinement session.
It was whether the habits started happening without being prompted.
Did someone challenge the solution? Did they ask what evidence we had? Did they make the trade-off visible? Did they think about the customer before the ticket?
That's when the change became interesting.
What I'd take from it
Product maturity isn't something you roll out.
You can introduce frameworks, ceremonies and templates.
But none of them matter if people don't understand why they're using them.
The shift happens when teams start asking better questions without being prompted. When they challenge the solution. When they make the trade-offs visible. When they think about the customer before the ticket.
That's when product thinking stops being a process and becomes a habit.
Raise the floor.
The whole team gets better.