Read the product reality
Use existing product evidence, stakeholder and user knowledge, artefacts, code and operating context. Do not repeat research that the team can already support.
How We Work
One product decision, carried across disciplines
Tcules works with founders and product, design and engineering leaders to understand a product condition, make the next consequential decisions and carry them into what gets built. The engagement shape changes; responsibility and evidence remain explicit.
Start with a working agreement
Before production, agree:
- product condition and intended change;
- decision owners on both sides;
- Tcules responsibility and client-retained responsibility;
- access, confidentiality and AI-use requirements;
- evidence available and missing;
- release and acceptance boundary;
- communication and time-zone overlap;
- what would cause scope to change.
The delivery loop
Make the decision visible
Represent objects, roles, rules, states, authority, evidence and alternatives. Use the smallest artefact that lets the right people challenge the decision.
Carry intent into implementation
Designers and engineers work through the state and technical boundary together. Tcules can own design, design engineering and software delivery where agreed.
Evaluate and continue
Test the risky condition, release in a credible slice, observe what happened and update the product decision.
Responsibility map
- 01
Entities
client domain owner, client product or technology owner, Tcules engagement owner, design, engineering, evidence, decision, acceptance and escalation.
- 02
Relationships
the client retains business, domain and policy authority; Tcules owns agreed product and delivery decisions; acceptance and escalation have named owners.
- 03
Responsive behaviour
desktop presents roles beside the delivery loop. Mobile presents the working agreement first, then each role and its decisions. Names are engagement-specific and are not hard-coded into reusable copy.
AI in the work
- AI-assisted delivery begins with the engagement's operating boundary: approved material, client tools and environments, confidentiality requirements, repository access, review owners and acceptance conditions. Client restrictions override Tcules defaults.
- Within that boundary, Tcules may use AI for research synthesis, product modelling, exploration, prototyping, code work, testing and documentation. A repeatable task may become a purpose-built agent or harness only when its inputs, outputs, failure states and review route can be made explicit.
- Human practitioners remain responsible for source interpretation, product judgement, sensitive-data decisions, code review and the released result. Generated output is treated as unaccepted work until it passes the checks appropriate to its consequence. If a system cannot produce a trustworthy result, the working model needs a visible route to retry, narrow the task, recover manually or stop.
- This is the operating direction Tcules now uses. Detailed public claims about particular controls remain bounded until those controls are audited across engagements.
Ways to begin
- a bounded audit or assessment;
- a product decision or capability;
- a 0-to-1 product slice;
- an embedded continuing responsibility;
- an end-to-end design and software delivery.