Approach
No methodology to buy into. Five steps that keep the technical and the commercial side of a problem in the same room.
Start with the outcome someone is accountable for, not the feature request that arrived with it.
Requirements arrive already translated, usually more than once. A customer describes a symptom, an account manager writes it up as a feature, and it reaches engineering as a ticket. The first job is to work back to what someone is actually trying to achieve and who is on the hook for it. That often changes the scope before a line of code is written.
Technical, commercial, contractual and organisational. Most of them are not written down anywhere.
The interesting constraints are rarely technical. A contract renewal date, a security review, a team that is already committed for the quarter, a legacy system nobody wants to touch. These decide what is possible far more often than the architecture does, so they get mapped early rather than discovered late.
The version that proves the thing and can be extended later. Not the version that looks impressive in a deck.
Credible means two things: it handles the cases that will actually occur, and it can grow into the full version without being thrown away. The riskiest assumption gets tested first. Everything that can be deferred is deferred, and the deferred list is written down so it does not quietly become technical debt.
Prototype it, ship it, or give your team what they need to ship it properly themselves.
Depending on the engagement this means writing the prototype, reviewing the implementation, or producing the specification, playbook and reference material your team builds from. The aim is always that your people can run and extend it once the engagement ends.
Agree what good looks like before the work starts, then check the result against it.
Measures get set at the start, while it is still possible to be honest about them. Time to first successful integration, support load, deal cycle length, hours returned to the team. Then the result gets checked against them, including when the answer is that it did not move.
The shape of it
Requirements do not go straight from a customer to a shipped feature. They pass through several sets of hands, and pick up constraints at every one.
Customer requirement
What was asked for
Discovery
What is actually needed
Commercial constraints
Architecture
How it will work
APIs
Product & engineering
What can be built
Data
Implementation
What ships
AI & automation
Business outcome
What it was for
Operating principles
A design that only exists in a conversation cannot be reviewed, priced or handed over. Most engagements produce a document someone else can pick up.
The part most likely to be wrong gets tested early, while changing course is still cheap.
Outside help that creates a dependency has failed. The test is whether your people can run it afterwards.
Including when the honest answer is that you do not need outside help for this one.
Scope changes get raised and discussed. They do not get quietly absorbed and then invoiced.
If a recommendation cannot be explained to the person paying for it, it is not finished.
Getting started
A short call first, to work out whether this is the right kind of problem. If it is, the next step is normally a scoped discovery exercise: conversations with the people closest to the problem, a look at the systems involved, and a written summary of what is actually in the way.
That summary is useful on its own. It sets out the options, what each one costs, and which risks are worth carrying. Plenty of engagements stop there, because by that point the team knows what to do.
Where the work continues, it continues under one of the four engagement models below, with the scope and the measures agreed before it starts.
Senior input on architecture, technical strategy, product direction or go-to-market, without owning delivery.
Regular sessions, design reviews and written recommendations.
A defined piece of work with a start, an end and an agreed output.
Scoped up front, priced as a project, delivered against a plan.
Ongoing access to senior technical and commercial expertise without hiring for the role.
A set number of days each month on a rolling arrangement.
Working inside your team for a defined period, with the same tools and the same standups.
Fixed period, agreed scope, working directly with your people.
Describe where it is stuck and you will get an honest read on what is blocking it and what it would take to move.