Beyond the methodology: 10 principles for how we work
I’ve been working recently with Public Digital on a project with the Dominican Republic government.
Something we’ve been reflecting on is how easy it is for teams to lose sight of what they are trying to achieve.
A project can become about completing Discovery, moving into Alpha, producing the right artefacts, running the next sprint, or getting to the next stage.
But following every step correctly does not guarantee that we are solving the right problem or creating a service that works.
There is no magic recipe.
The right way of working depends on the problem we are trying to solve, the context we are working in, the people involved and what we are learning along the way.
A methodology should help us learn and improve. It shouldn’t become a sequence of steps that we complete before declaring the work done.
So, rather than prescribing another methodology, let’s make visible the principles that sit underneath the way we work.
Defining what really matters
I ran a workshop at Public Digital that asked: What are the things we really want teams in the Dominican Republic to remember, whatever type of project they are working on?
Once I had collected ideas from the team, I drafted a set of principles.
I took these to the client in the Dominican Republic to test them out. I wanted to get their thoughts on whether they would be useful for teams, check that they made sense in the local context and language, and see whether they would be willing to stand behind them.
The feedback was positive, and I did a couple of iterations after that.
And here they are:
1. Understand the problem before designing the solution
A project brief rarely tells the whole story. It might arrive as a proposed solution, a policy objective, a user need or a description of a problem. But it is often based on assumptions.
Our job is to understand what is really happening before jumping to solutions.
That might mean understanding how people currently navigate a service, where decisions get stuck between institutions, or why a particular regulatory requirement exists in the first place.
Don't just accept the problem as given. Understand it. Test it.
2. Let evidence guide decisions
Good ideas are not enough. We need to learn whether they work. Reduce the risk of implementing solutions based on assumptions.
Research, user testing, data, technical experiments and what we observe in the real world all help us reduce uncertainty and make better decisions.
Testing a prototype before building a platform can prevent months of work on the wrong thing. Piloting a new governance mechanism can reveal problems before it becomes institutionalised. Analysing regulatory burden can show us which requirements are actually causing the most difficulty.
The earlier we learn, the less risk we carry forward.
3. Keep the purpose visible
It's easy for activities and deliverables to become goals in themselves.
“We need to build a platform.”
“We need to create a committee.”
“We need to reduce the number of requirements.”
But these are means, not ends.
The purpose should remain visible throughout the work: to create better outcomes for people and the organisations that deliver services to them.
Keeping that purpose in view helps teams make better decisions when priorities compete or when the original plan no longer makes sense.
4. Give teams the autonomy to adapt
Different problems need different approaches.
A team working on a mature digital service may need analytics and performance data to improve the service, instead of extensive user research. A team designing a new governance model may need participatory workshops and pilots. A regulatory project may require legal analysis alongside research with the people affected by the regulation.
We don't need every team to work in exactly the same way.
The principles are shared; the methods can adapt.
This requires teams to have enough autonomy to make those decisions — and leaders to create the space for them to do so.
5. Deliver early and continuously
We don't need to wait for perfection before delivering something useful.
We can build, test, learn and improve incrementally.
And importantly, delivery isn't the end. Services are never really finished.
People's needs change. Policies change. Technology changes. What works today may not work tomorrow.
A good service therefore needs the capacity to keep learning and improving after launch.
6. Make the work visible
Making work visible is about much more than transparency for transparency's sake.
When research, decisions, risks, progress and problems are visible, people can contribute earlier. Teams can spot issues sooner. Institutions can understand what is happening. And stakeholders can see the work itself rather than relying on status updates.
A prototype, a roadmap, a backlog or a show and tell can often create a better conversation than another meeting about what the team might build.
Show the work. Make progress visible. Share what you're learning.
7. Share responsibility for the service.
Complex public services rarely sit within a single team or institution.
A digital team cannot make a service successful on its own if policy and operations are not involved. Or if another institution controls a critical part of the user journey. Likewise, a new governance model cannot work if the people expected to operate it don't have ownership.
Success needs to be shared.
That means clear roles, clear decision-making authority and clear ways of resolving blockers — without creating unnecessary layers of governance.
Everyone involved has a role in making the service work. It’s important to define those and have a shared view.
8. Work in multidisciplinary teams and in collaboration with institutions
Complex problems need different kinds of expertise.
Service designers, researchers, content designers, developers, product people, policy specialists, lawyers, operations teams and institutional experts will each see different parts of the problem.
Bringing those perspectives together helps us create solutions that are not only useful for people, but also viable for institutions and possible to implement.
And collaboration shouldn't happen only between disciplines. The institutions that will operate and sustain the change need to be part of the work too.
9. Align around outcomes and define success criteria together
Being busy isn't the same as making progress.
A team can produce lots of documents, run lots of workshops and launch a platform — and still fail to achieve the outcome it set out to create.
That is why teams need a shared understanding of what success looks like.
For a digital service, that might mean fewer errors, faster completion or greater accessibility.
For a governance project, it might mean faster decisions, clearer responsibilities or fewer unnecessary escalations.
For regulatory simplification, it might mean less time, cost and administrative burden while still achieving the intended policy outcome.
Measure what matters, not just what gets delivered.
10. Use AI as a starting point
AI gives teams new ways to move faster and work with large amounts of information.
It can help analyse documents, identify patterns, generate first drafts, explore ideas and create prototypes quickly.
But AI doesn't remove the need for judgement.
Its outputs still need to be questioned, reviewed and improved. Most importantly, AI doesn't replace research, professional expertise or testing with the people who experience the service.
AI can accelerate the work. It cannot replace the people responsible for making good decisions.
What this looks like in practice
To help teams use these principles, I created examples to illustrate how they could apply to different types of projects: designing a digital service, developing a new governance model or simplifying regulation.
The main point was to show that, whatever the work, the underlying principles remain consistent.
Here are some of the examples I shared:
Principles, not process
Taken together, these principles describe something quite simple.
For teams to be able to:
Test → learn → deliver → measure → improve. And repeat.
The exact tools, techniques and methods used to do this will vary.
And that's the point.
Success will come because the team understood the problem, learned from evidence, adapted to its context and ultimately created something that works better for people.
The methodology is a means to get there. The principles are what matter.