This post is part of our Creating an Outcomes-Driven Culture in Public Sector Delivery series.
If you’re a Senior Responsible Owner (SRO) or stakeholder, then keeping a digital project on track can feel frustrating and confusing at times. Projects can become bogged down, take wrong turns, or lose sight of the user and it’s hard to spot when things start to go off course.
Governance meetings ought to help but they’re infrequent and one step removed from the activity. The real action happens outside of those meetings.
What’s more, when one sees a project is going off track one’s instinct is to increase control and governance—make the requirements even more specific and demand even more detailed progress reports. But specific requirements just lead to questions and pushback from the team. Detailed reporting takes the team away from delivery. Admin instead of action.
Attempting to fix delivery only pushes it further off track.
Done properly, Product Management can fix those problems, delivering outcomes without killing agility. It does that by providing clear direction, ensuring good judgement, and keeping the focus on users.
Signs there’s a lack of direction
1. The team is busy but not moving
Digital teams are rarely short of activity. Sprints are running, boards are full and people are solving difficult problems, but it is perfectly possible for everyone to have plenty to do without the programme becoming any closer to releasing something useful.
Usually, this is not about effort. It is about nobody having identified the spine of the service. What must work first? What would a useful initial version look like? Which work moves the programme forward, and which can wait?
A good product manager helps the team find its focus. It’s about knowing that the car needs an engine and wheels – the decision about what colour to paint it can come later.
2. Nobody is telling the story upwards
As a stakeholder, you need more than milestones and status reports. You need to understand what is being built, why choices have been made and how the work contributes to the outcome for which they are accountable.
When that story is missing, the delivery can feel disjointed and irrelevant.
Imagine somebody is rewiring your house and you cannot see much progress, so you begin asking what every cable does. The electrician can explain every connection, but you may still have no idea whether the lights will work.
The same happens in digital projects. Without a strong vision, a tool like a CRM can easily become a collection of irritating and complex forms that staff must complete. Admin for admin’s sake. A product vision like ‘design the hive mind where colleagues collaborate to make customer interactions feel seamless and effortless’ brings to life the ‘why’ behind the ‘what’. The forms remain, but now the team is focussed on making them useful and usable, and stakeholders can see the rationale behind design decisions.
3. Requirements are treated as fixed
Many programmes begin with requirements shaped through policy work, a business case or procurement completed months or years earlier. Those requirements matter, but they are not the same thing as the outcome.
Technology develops, operating conditions change and research reveals things that were not known when the specification was written. Teams may also discover that a requirement is expensive, impractical or simply not useful. Meanwhile, there may be new opportunities to deliver something that is relevant today rather than meet the requirement of a year ago.
A product manager keeps returning to the intention behind the requirement. Why is it there? What problem was it meant to solve? What do we now know that we did not know before?
The important question is not simply whether the team has delivered what the document says. It is whether it has delivered to the intention. That does not mean reopening every decision, but it does mean avoiding the faithful delivery of something that sounded plausible 18 months ago and is out of date when it reaches the public.
Signs that no one is exercising judgement
4. A technology decision has not been stress-tested
Technology choices can gather momentum quickly. A platform looks promising, a supplier proposes an established solution or a team becomes enthusiastic about an approach. Once time and money have been committed, questioning it becomes harder.
A product manager is not there to overrule architects or technical specialists. Their role is to make sure the important questions are asked before the programme becomes dependent on the answer. Has the approach been tested where it will operate? Will it work with existing systems and data? Have alternatives been explored? What evidence would make the team change its mind?
A solution can look credible in isolation and still prove unworkable in practice. Finding that out early is not failure. It is useful information, provided the programme responds to it.
5. Risk belongs to everybody and nobody
Risk registers are valuable, but they rely on people feeling able to raise the risk. In a pressured programme, it can be difficult to say that the date is unrealistic, the supplier relationship is becoming difficult, or the chosen technology may not support the service.
The longer confidence in the plan has been maintained, the harder it becomes to challenge. Stakeholders may respond by holding the team more tightly to the original dates and requirements, which can make people even less likely to surface problems while there is still time to act.
A good product manager helps create a healthier dynamic. It’s not useful to discuss who made the wrong call six months ago, but what the team now knows and what the best next decision is. By prioritising effectively, managing dependencies, or making a change of direction they can pro-actively manage risk.
6. Suppliers are delivering the contract, not the outcome
Contracts need to define responsibilities and deliverables, but they cannot fully describe a service that has not yet been built.
Over time, an outcome discussed during procurement can become a series of tasks delivered to the letter. Each organisation may complete its part while the programme as a whole moves no closer to a coherent service.
It is like delivering a pile of bricks to the front door and explaining that nobody said anything about building the wall. The contractual output may have been met, but it is not the outcome anybody wanted.
Commercial and legal expertise remain essential. Product management complements them by keeping suppliers, internal teams and operational partners connected to a shared goal. The question is not only whether the contract is being delivered, but whether what is being delivered still serves the outcome.
Signs the project is losing legitimacy
7. The service passes the assessment but fails the frontline test
The ultimate test of legitimacy is: does it serve the needs of the members of the public or organisations that need to interact with the state?
A programme can pass formal gates, meet contractual commitments and complete its roadmap while still producing an experience that is no better than the one it replaced.
Service assessments provide important scrutiny, but they happen at particular moments. A good product manager keeps absorbing user research and asking what it means throughout delivery, rather than treating research as something that happened during discovery and can now be filed away.
They also look beyond the person directly using the screen. In the CRM example, the immediate user may be a civil servant entering information, but the ultimate beneficiary is the citizen making contact. If the system works well, they receive a more consistent response, encounter fewer errors and do not have to repeat their story.
The experience of frontline staff matters too. Tools that support a good service make the work feel meaningful, while a process that frustrates the public frustrates the people delivering it as well.
The real test is not simply whether the product has passed an assessment. It is whether the service works for everyone who depends on it.
Owning the outcome continuously
If those problems feel familiar to you, that’s not a coincidence. Often, product managers shrink to manage documentation rather than outcomes.
Good product management isn’t about paperwork. Backlogs, roadmaps, objectives and research findings all matter, but a focus on outcomes is what keeps projects on track.
Of course projects are team efforts. A good delivery manager makes sure the process is followed. A good PMO has your back when it comes to reporting. But a good product manager is there to make sure the right outcomes get delivered.
If you’re experiencing more than one of those seven problems, try asking this question in your next programme board: “Who in this room owns the outcome, not just their piece of it?” If the honest answer is “no one,” then it’s time to upgrade your product management.
If you’re interested in learning more about keeping your digital project on track, please get in touch via our website, or find out more about Digital Service Delivery from Made Tech.
About the Author
Giles Colborne
Head of Product and Innovation
