Capability file / 002Independent / Product-led
Ways to work together
Shape it.Build it properly.
Protocol 07 works across product direction, experience design and full-stack delivery—enough range to keep one clear idea intact from first question to working release.
0401Define
Product direction
Make the problem precise before making the product bigger.
Turn an early idea, an operational problem or an existing product opportunity into a clear product direction. The outcome is a focused release with a reason for every important decision.
- Problem and audience definition
- Product scope and release priorities
- User journeys and decision logic
- Technical direction and delivery plan
02Design
Experience systems
Design the path, the interface and the rules that connect them.
Shape the way a product behaves before polishing how it looks. Complex choices become understandable flows, responsive interfaces and reusable patterns that can grow without losing coherence.
- Information architecture and user flows
- Interaction and interface design
- Responsive prototypes
- Visual language and reusable components
03Build
Full-stack delivery
Move from approved direction to software people can actually use.
Build the working web product, including the interfaces, product logic, data connections and deployment path. Delivery stays tied to the original problem rather than accumulating features by default.
- Production web application
- APIs, data and service integrations
- Responsive and accessible implementation
- Testing, deployment and release checks
04Evolve
Product improvement
Use what the product has taught us to decide what changes next.
Review an existing product, find the friction that matters and improve it in deliberate releases. This can cover experience, performance, reliability, maintainability or the shape of the product itself.
- Product and experience audit
- Prioritised improvement plan
- Targeted redesign or rebuild
- Release validation and follow-through
Working protocol
How decisions are made
Clarity is part of the deliverable.
01Problem before output
The work begins by understanding the decision, task or constraint the product must improve.
02One useful release
Scope is shaped around the smallest version that can be credible in real use.
03Reasoning made visible
Important product decisions are explained so they can be tested, challenged and improved.
04Build for what comes next
The first release should create a stable base without pretending every future requirement is already known.