06. Product & Tech — Delivering the Promise

Part 2 — Where I’m spending most of my time. This chapter is intentionally the deepest in the handbook. The product is where the brand becomes real, and the tech is the substrate that decides whether it can stay real over time.

The Principle

The product is the brand made tangible. The tech is the substrate that decides whether the promise can be kept at the second customer, the hundredth, and the thousandth. Every release either strengthens the promise or quietly erodes it.

Why It Matters

Customers do not experience the pitch. They experience the product. Every load time, every error message, every onboarding step, every email triggered by the system — that is the brand. The marketing site can say whatever it wants; the product tells the truth.

Underneath the product is the tech. Most non-technical leaders treat tech as an implementation detail. It isn’t. Tech decisions made in year one become the constraints of year three. A team that ships fast on a foundation that can’t bear weight is just borrowing trust from its future self. A team that builds a foundation nobody is using is borrowing trust from its present self. Both are dangerous; neither is virtuous.

Product and tech share one job: make the promise easier to keep, at every scale you intend to operate at.

A Story

The Mechanics — Product Shape

1. One product to the customer, many services behind the gateway. From outside, the customer sees one product — the one that delivers the promise. From inside, that product is composed of small, single-focus services that work together like a swarm. The gateway is the contract; everything behind it can change. This shape is what makes the product look coherent to the customer while letting the team evolve, replace, and upgrade pieces independently.

2. Simplicity beats feature count. Deliver on the promise really well, with as few features as possible. Every additional feature is a new sub-promise to keep, a new surface to support, and a new way for the core promise to get diluted. The product that does one thing the customer hires it for, exceptionally well, beats the product that does ten things acceptably. Resist the temptation to grow the surface to match the spreadsheet.

3. Don’t build what the world has already built. Accounting, project management, document storage, scheduling, payments, email — almost every company needs them; almost no company should build them. Use external tools for the things everyone does. Save your build energy for the thing only you can build: the part of the product that lives inside your promise. Every service you adopt for the generic parts is a service you don’t have to maintain forever.

4. Every release answers one question: does this make the promise more or less credible? This is the only ship/no-ship gate that matters. Features that look good in the demo but leave the promise more fragile (worse performance, more support load, more confusing UX, more bugs in the older surface area) are net-negative even when they close a deal. Make this question explicit in your release review.

5. Ship for the daily user, not the demo. Demos optimise for first impression. Daily use optimises for the hundredth repetition. These two are usually in tension. The product that wins long-term is almost always the one that’s slightly worse in the demo and much better on day 30. If you have to choose, choose day 30.

6. The roadmap is a promise too. Anything you commit to publicly — to customers, to the sales team, to the board — becomes a sub-promise of the brand. Be slow to promise. Be fast to deliver what you did promise. A small roadmap kept is worth more than a large roadmap missed.

7. Build vs. buy vs. partner is a brand question. Every dependency you take on is a piece of someone else’s brand becoming part of yours. If their reliability, ethics, or roadmap diverges from yours, your customers experience that divergence. Buy when the thing is not central to the promise. Build when it is. Partner when you can hold the other party to the same standard you hold yourself to.

8. Listening loops over surveys. Sit with customers using the product. Watch where they hesitate. Read every support ticket in the first 30 days of a new feature. The friction that doesn’t show up in metrics is what kills trust over time.

9. Distinguish buyers from users. The person who signs the contract often has different needs from the person who opens the product every morning. Both matter. A product that delights the buyer and frustrates the user has a renewal problem you won’t see for 12 months.

The Mechanics — Architecture & Design

10. Design and plan up-front; it is cheaper than pivoting. The cost of designing carefully before building is almost always less than the cost of building the wrong solution and having to walk it back. A week of design that prevents a quarter of wrong build pays for itself many times over. Up-front design does not mean waterfall — it means thinking before typing. Sketch the shape, name the trade-offs, agree on the interfaces, then build.

11. Small, single-focus services. Each service does one thing well, owns its data, and exposes a clear interface. Composing them produces the product the customer sees. Smaller scope means:

• Faster build and test times.
• Faster CI pipelines.
• Easier replacement when something better comes along.
• Smaller blast radius when something breaks.
• Easier to reason about — and easier for a generative AI agent to reason about with a tight context.

12. Design for generative AI from the start. A small, single-focus service with a clear interface is exactly what an AI assistant (or an MCP tool) can use well. Design services with tight, well-named contexts and clean tool surfaces. Use MCP and similar protocols to let the system go where the customer is going — meeting them in their existing tools rather than dragging them into yours. This is no longer a future consideration; it’s a present design constraint.

13. Tracer bullets first. To start any new piece of work, fire a tracer bullet: build the simplest possible end-to-end path through the system, all the way to the final state, even if every step is a stub. This sets up the skeleton — the scaffolding, the deploy path, the wiring — so that from that point on, every conversation is about business logic, not plumbing. Tracer bullets pay back instantly: you can see the shape of the solution before committing to any of it.

14. Composability over completeness. Build the system so pieces can be swapped, replaced, or upgraded as better options appear. This is the long-term insurance policy: when a better tool, a better service, a better model appears, the architecture can absorb it instead of resisting it.

15. Build for the second customer, refactor for the tenth, rewrite for the hundredth. Premature architecture is a tax on the present that may never pay back. Premature shipping is a debt on the future that always comes due. The discipline is to know which one you’re doing and why. The right level of engineering is one step beyond what the current scale demands — not five.

16. The boring tech bias. For everything that isn’t central to your differentiation, choose the boring, well-understood, well-supported option. Save your innovation budget for the parts of the system where being unusual is actually an advantage. Most teams spend their innovation budget in the wrong places and have nothing left for the work that mattered.

The Mechanics — Engineering Practice

17. Two-week cycles. Two-week sprints are the sweet spot. One-week cycles are too much reporting and too little time to actually move the needle. Three-week-plus cycles are too slow to feel real progress and let focus drift. Two weeks is long enough to ship something meaningful, short enough to course-correct, and matches the rhythm of human attention.

18. Tools that match the practice.

• Linear for project management — fast, opinionated, and stays out of your way.
• Slack for the water-cooler conversations and as the integration hub: pipe in notifications, support events, PR activity, alerts. Slack is where the team’s nervous system lives.
• GitHub for everything code: repositories, CI, package registry, open-source publishing, PRs, and documentation. Keep the source of truth for code and code-adjacent decisions in one place.

19. PR-driven collaboration. Open a PR for every ticket, early, with a WIP label. The PR is not the end of the work — it is where the technical discussion starts. Announce new PRs in Slack when work begins, so the team can follow along. This turns PRs into a collaboration surface, not just a review surface.

20. PR standards make history searchable. Use Conventional Commit-style prefixes (feat:, fix:, chore:, refactor:, docs:, test:) so the key events in a PR’s commit history are easy to scan. The commit log becomes a navigable narrative of the work, not a wall of “wip” and “fix stuff.”

21. PRs build redundancy and shared knowledge. The point of code review is not gatekeeping — it is redundancy and learning. Every PR is an opportunity for another engineer to understand a piece of the system they didn’t write, and to spot what the author missed. A team that reviews each other’s work seriously has no single points of failure in its understanding.

22. Tech leadership: opinionated, but evidence-driven. The tech leader’s job is not to be neutral. It is to hold a sharp view of how this team builds, and then to update that view in the face of evidence. Soft opinions slow teams down (everything is up for re-debate). Closed opinions break teams (good evidence is ignored). Hold opinions hard until shown otherwise; change publicly when shown.

23. Technical debt is a trust ledger. Every shortcut is a future promise to fix it. The debt you took on knowingly, named, and tracked is healthy. The debt you took on without naming it is a trust breach waiting to happen — against your future self, your future team, and eventually your customer. Make the ledger visible. Pay it down on a cadence.

24. Reliability is a product feature. Uptime, performance, correctness, recovery from failure — these are not “ops concerns” downstream of product. They are how the promise stays kept on day 100. Treat them with the same rigour you treat any visible feature. Budget for them. Staff for them.

25. Observability before optimisation. You cannot keep a promise you cannot measure. Before you optimise anything — latency, conversion, retention, cost — make sure you can see it. Most premature optimisation is really blind optimisation.

26. Documentation as a leadership tool. Written architecture decisions, runbooks, onboarding docs, PR descriptions — these are not bureaucracy. They are how you scale your judgement without being in every room. A team that documents its decisions can disagree productively. A team that doesn’t will re-litigate the same arguments every six months as people turn over.

27. Security and privacy are brand promises. A breach is a brand event before it is a technical event. The customer does not care about the CVE; they care that they trusted you and you weren’t ready. Treat security as part of the promise, not as a compliance afterthought.

Questions to Ask Yourself

About the product

• Does your last release make the promise more or less credible?
• Are you optimising for the demo or for day 30?
• What is on the roadmap that you’ve committed to publicly but quietly know you can’t ship on time?
• Which of your dependencies’ brands are you exposing your customers to?
• When did you last sit with a customer using the product in their environment?
• Which features in your product are not central to the promise — and would the product be stronger without them?
• What are you building that you could rent, buy, or integrate instead?

About architecture & design

• Where did you skip up-front design and pay for it later?
• Are your services small enough that one person can reason about one of them in a sitting? Small enough that an AI assistant can?
• When was the last time you fired a tracer bullet before committing to a build?
• If a better external tool appeared tomorrow for one of your internal services, how painful would the swap be?

About engineering practice

• Is your sprint length helping the team move the needle, or generating reports?
• When a new PR opens, does the team know? Can they jump in early?
• Can you read your commit history and reconstruct the narrative of the work?
• Are PRs in your team a place for learning, or a place for gatekeeping?

About the tech foundation

• Where is the named, tracked technical debt — and where is the hidden kind?
• Is your team building one step beyond current scale, or five?
• Can you see the things you claim to care about? (Latency, errors, conversion, cost, etc.)
• If your senior engineers left tomorrow, would the next engineers understand why the architecture is the way it is?
• Which “exciting” technology in your stack would be safer as a boring choice?
• When did you last test that you can recover from the failure mode you fear most?

Anti-patterns

Product

• Roadmap-by-loudest-voice. Building what the latest big customer demanded, or what the founder thought of in the shower, or what sales needs to close this deal. The promise gets diluted one priority shift at a time.
• Shipping for the demo. Features that look good in a 30-second walkthrough and feel bad in week three of daily use.
• MVP as an excuse. Using “minimum viable” to justify shipping something that contradicts the brand’s promise.
• Feature accretion. Adding without ever removing. The product becomes a museum of every customer you tried to please.
• Rebuilding the generic. Spending months reimplementing accounting, scheduling, or project management because “ours will be tailored.” It almost never is.

Architecture & design

• Skipping the design conversation. Diving into code because design “slows things down.” The pivot that follows costs ten times what the design would have.
• The monolith of convenience. Putting everything in one service because it’s faster today, then paying for it in CI time, deploy risk, and team coupling for the next three years.
• Over-services. The opposite failure: cutting things so fine that the operational overhead dwarfs the development gain. Services should follow the seams of the domain, not the seams of the org chart.
• Resume-driven architecture. Choosing technologies for what they’ll look like on a CV instead of what the company actually needs.
• Heroic rewrites. “Let’s rewrite it” as a substitute for understanding why the current system is fragile. Almost always more painful than the team imagines.

Engineering practice

• The ceremony spiral. Adding standups, retros, plannings, demos, and check-ins until the sprint is mostly meeting. Two-week cycles should leave room for the actual work.
• Late PRs. Opening the PR only at the end, when the discussion can’t change anything. The PR becomes a formality instead of a collaboration.
• Invisible debt. Shortcuts taken under deadline pressure that are never named, tracked, or paid back. The team only discovers them by tripping over them under load.
• Process as a substitute for judgement. Heavy review gates and templates that punish thoughtful engineers and don’t catch the careless ones.
• The 10x engineer trap. Building the system around one exceptional person whose departure becomes a brand event.

One Thing to Do This Week

Pick the next non-trivial piece of work on your team’s roadmap. Before any production code is written, do two things:

1. Design pass. A one-page sketch of the shape, the trade-offs, and the interfaces. Share it. Invite challenge.
2. Tracer bullet. A working end-to-end skeleton, even if every step is a stub, deployed to wherever it’ll eventually live.

Then — and only then — start the real build. Notice how much the early conversation changes the final design.