Jul 24, 2026
That was how the company described the problem.
A company of about 35 people brought me in as a fractional Head of Product
Fractional Product Leadership. They had more than 50 ideas competing for a small engineering team, with no agreed way to decide which ones deserved investment.
The founder-CEO pushed some of his ideas through the CTO. Other people went directly to the CTO with requests of their own. More than 50 ideas were sitting in a shared Google Sheet.
Most ideas came from one-off client requests, internal suggestions or conversations with the CTO. A few were the CEO's own. None had been scored or ranked. They had only been T-shirt-sized for effort and nothing had been formally killed or parked.
The engineering team already had about 7 projects in progress.
A few weeks before I arrived, the CEO had paused all new development. Nothing significant had shipped in three months, despite the team adopting AI dev tools. He wanted to understand why before funding more work.
The CTO ran a small engineering team and also owned "product" by default. He was spending about 2 days a week on product decisions, but the product work alone needed closer to 3 or 4.
A lot of it arrived through Slack messages starting with "just a quick one for you". Every problem eventually became an engineering request. Nobody was asking whether software was the right response, what outcome it was meant to create or whether it justified the investment.
I ran 4 sessions in the first week, one each with the CEO, CTO, commercial lead and CFO. Whenever somebody told me what they wanted built, I asked:
A lot of questions, I know. The questions, though, made the gaps visible before we started debating solutions.
As expected, most of the answers did not line up. Around a dozen out of the 50 ideas had no clear goal behind them. Some technical debt items had no explanation of the risk they were meant to reduce. Other ideas were based on a customer request, with no work done to understand the underlying problem or whether other customers shared it.
The leadership team was comparing proposed solutions built on different assumptions, not ranking well-understood opportunities.
The CFO had no visibility into almost half of the decisions already made. Revenue impact, ongoing cost and commercial assumptions were not consistently checked before work reached engineering. He often found out after the investment had effectively been made.
The language gave the problem away. Every conversation was about projects: the client portal, the pricing revamp, the dashboard update, improvements to feature X. And nobody used the word "goal" unless I asked for it first. Even then, nobody could tell me which goals mattered most.
By the end of the first week, the CEO and I had reduced the company's 5 priorities to 3.
I use FigJam to visualise strategy, Objectives and Key ResultsA goal-setting framework that pairs a clear objective with measurable results showing whether progress was made.Learn more, Goals, etc and then use ChatGPT to add a bit of magic
No project could move forward without supporting one of those goals, although alignment alone was not enough to justify building it.
“Reduce churn” alone is just the target. For retention, we needed to understand why customers were leaving. Was the issue in the product, onboarding, account management, service reliability or pricing?
For revenue, we needed to know what additional value customers would pay for. That might mean a new capability, different packaging, a commercial conversation or better adoption of something that already existed.
For time to market, we needed to identify where work was actually getting stuck.
The team had 7 projects in progress, more than 50 requests behind them, multiple people feeding work directly to the CTO and no shared view of what mattered most. AI could speed up parts of delivery but it could not resolve unclear priorities.
In week 2, we introduced ICE frameworkA lightweight way to compare product ideas using Impact, Confidence and Effort.Learn more scoring:
I use ICE with the confidence meter. Recommend reading Product Discovery With ICE and The Confidence Meter by Itamar Gilad.
It gave us a consistent way to challenge the backlog. A request could no longer be called "important" without saying what it was expected to change.
The greater the effort or risk, the stronger the evidence needed to support the impact estimate. ICE was only the first filter. One customer asking loudly did not count as high confidence.
Larger or riskier items still needed answers to these questions:
At this stage, rough answers were enough. The aim was to expose assumptions without spending weeks building a business case for every idea.
The second job in week 2 was to split responsibilities between the CTO and the future Product functionThe people, responsibilities and decision mechanisms that turn customer and business context into product direction.Learn more.
The company needed permanent product leadership. The CTO had ended up doing the job by default, alongside engineering, architecture and delivery. I worked through the split with him.
Product would turn company goals, customer evidence and commercial context into recommendations about what to invest in next and why. The CTO would remain responsible for technical health, feasibility, architecture, engineering capacity and delivery.
Both sides would work through value, risk, feasibility and cost together. Neither could commit engineering capacity alone. We wrote down what stayed with the CTO, what moved to product and what required a shared recommendation.
In week 3, the CTO and I reviewed every idea in the backlog.
We grouped duplicates, challenged the stated problem, identified the goal each item supported and recorded the evidence behind it.
Most of the backlog failed the first review (good!)
Some had no connection to the three goals. Others were solutions without a clear problem or one-off customer requests that didn't justify a general product investment. Some belonged with operations, account management, commercial or technical health. Others may have been worthwhile but there was no evidence that they deserved capacity now.
9 items had enough alignment and evidence to put in front of the CEO.
We capped the shortlist at 3 items per goal, so no single area could dominate the conversation before the CEO weighed trade-offs across the whole portfolio.
Everything else was removed, merged, redirected or parked with a reason attached.
4 of the 9 were already in the engineering pipeline.
Starting work did not mean the company should finish it.
The CEO reviewed those 4 and kept 2:
The other two went back to the backlog with the reason recorded.
The remaining 5 went through the same review.
2 were large enough to require discovery before approval. The other 3 were parked.
That left four active items:
Each had a goal, intended outcome, evidence, assumptions, recommendation, owner and next decision.
Week 4 closed with the first Betting Table (borrowed this term from Shape Up).
The CEO had all 9 items in front of him, with a recommendation attached to each one.
For each item, he could see:
He made the decisions in under an hour.
Previously, the same work would have taken weeks of side conversations and repeated explanations.
The CEO still made the final investment calls, but he was now choosing between documented bets rather than reacting to disconnected feature requests.
The immediate delivery sequence came out of that meeting and he signed off on it.
The CTO could protect engineering capacity, finish the work the company had chosen to retain and create room for technical improvements.
We agreed to run the Betting Table fortnightly at first, then move to a monthly cadence once the team was familiar with the process.
Its job was to decide what deserved investment, what needed discovery, what should stop and what would not receive engineering capacity.
4 weeks wasn't enough to prove the selected bets would cut churn, lift revenue or speed up time to market. It was enough to change how the leadership team allocated engineering investment.
The leadership team now had:
Engineering was no longer the automatic response to every customer request, internal problem or executive idea. Some ideas didn't support the goals. Others needed more evidence or didn't belong in engineering at all.
The work that remained had a clearer explanation of why it mattered and why it deserved capacity now. The next phase was about improving the evidence.
The team already spoke to customers, but it lacked a structured way to turn those conversations into investment decisions. A feature request is a signal, not evidence that the feature should be built.
You need to know what they're trying to do, how often the problem occurs and how painful it is. You need to know how they deal with it today and whether solving it would affect buying, adoption, expansion or renewal.
The company also needed to look beyond current customers. It wasn't yet folding lost deals, churned accounts, market shifts or competitor moves into the process. That was phase 2.
| Problem | Fix |
|---|---|
| Nobody owns the "no" | Product and engineering prepare a recommendation, the Bet Board makes the trade-off, and the decision is recorded |
| Engineering is the default answer | Ask what outcome is needed and whether software is the best response |
| Backlog items have no metric attached | Require every proposal to name the goal and expected outcome |
| The team talks in projects, not goals | Start with the goal and problem before accepting a proposed solution |
| One person owns product by accident | Agree what stays with the CTO, what moves to product and what must be shared |
| Decisions happen in hallways or inboxes | Review recommendations through a recurring Bet Board |
| Financial impact is checked too late | Test the commercial logic before committing engineering effort |
| A high score greenlights risky work | Use scoring as a first filter, then review value, cost, feasibility and risk |
| Customer requests become features | Investigate the problem behind the request and how widely it is shared |
| Delivery feels slow despite better tools | Check work in progress, decision delays and changing priorities before blaming engineering speed |
Pro Tip: When a leadership team talks almost entirely in projects rather than goals, the problem usually sits above the backlog.
It is hard to argue about which projects matter when there is nothing specific enough to argue against.
The company started with:
Which features should engineering build next?
4 weeks later, the question was:
What outcome are we investing in and why is this the best way to create it?
If this sounds familiar, get in touch.
Keep reading
Levels is running four products and ~$3M in revenue, solo. This used to be the exception. It's becoming the norm. Marc Lou ships a new product every few weeks b...
There are two lists. One of them gets all the attention. The wishlist is the obvious one. Every team has one and it tends to grow on its own without any editin...
Cross-functional planning used to take us 2 weeks before AI. Now AI got it to 2 hours. However, the delays seem to be exactly the same length they've always bee...
I'm a father of 3 from Sydney, a product and technology leader. I write about leadership, product management, technology and the messy reality of making work work.
I'm currently building and experimenting with a mildly alarming number of things, and helping companies solve product problems. I also founded SoundingBoard, practical peer exchange for product people. Connect via LinkedIn, or follow me on X.
Subscribe to the best posts on product, strategy, and AI. Just one email a month.
