How to Deliver Delightful Tech Product - An Overview

Culture

Everything starts with the culture. For success, there are two aspects to this.

1. The organic culture

Be kind, supportive, decent, respectful, progressive. If the idea of “being woke” offends you then you’re probably going to screw this part up so take a big step back and remember: Treat each person as an individual, each with their own strengths and weaknesses, their own particular fears and delusions.

As leader you must embrace these characteristics and help each person get to know themselves better as part of the journey. These are not drones; they are delicate humans.

Everything — absolutely everything — is a product of your organic culture so this aspect needs to be absolutely nailed before you can do anything effective in terms of delivery.

2. Embrace Product Culture

Product Culture is key — Everything should be about product. The only reason the tech team exists is to deliver product. Don’t get lost in architectural or planning fantasy.

How to tell if you’re doing Product Culture? Your life revolves around the following values:

• Prototypes / experiments, as many as possible given the timebox constraints (see later section)
• Scrap estimates and modular roadmaps. “March 18: Implement Reporting v1” — What does this even mean?
• Focus on delivery of business value (e.g. “reduce data connection failures to < 5%”), not components (e.g. “new connection dashboard”)
• Hand down Problem Statements, not Requirements. “The buying user can’t see how much gift token they have left” will yield far better and innovative experiences than “add a running gift token total to the menu bar”
• Validate first. Do not leap to Big Build. It’s slow, expensive and — if you do it first — it will be wrong, I promise you.
• Deliver the smallest item you can to validate this iteration, every time. Don’t be seduced by trying to get the whole feature built in one go. Learn the breadth value — and speed — of incremental iterations.

For many, the above is nothing new, especially if you are product-focused and / or subscribe to the wonderfully clear thinking of Marty Cagan and others. Yada.

BUT how do you take all these values and lofty intentions and get them to result in beautiful tech product? Read on.

The Process

Overview

Jumping straight in, the cycles go like this:

1. Organisation Objectives [set quarterly by The Leaders]
2. Product Objectives — qualitative, stated aspirationally (e.g. “dramatically improve conversion”) [quarterly]
3. Product Key Business Results — quantitative and measurable without dispute (e.g. “increase % of users who share accounting data to 85%”, “reduce % of helpdesk tickets regarding signup to 2% of new users”) [quarterly]
4. Problem Statements to address (e.g. “users find the Xero connection process tricky”, “signup form only accepts mobile numbers”, “nobody trusts ‘sign up with Twitter’ anymore”) [reviewed every 2 sprints]
5. Prioritise Problem Statements - Problems are WAYYY easier than features / targets to prioritise [ahead of every sprint]
6. Innovations / experiments / prototypes to identify and validate solutions to Problem Statements [timeboxed into a sprint]
7. Craft Agile minimal scope stories to deliver working versions of validated prototypes from the previous step
8. Story refinement [ongoing, as and when. Avoid fixed lengthy refinement sessions.]
9. Sprint Planning [top of each sprint]
10. Tech Planning [as each story comes into play]
11. Actual development work

Involve everyone, all the time

Bring everyone on the journey — Involve your tech teams, designers and testers (if you have them) from as early as you can.

Whatever you do, do NOT make it a production line where you “add tech at the end”. This will be awful. Each piece of work needs to arise from a round table of inter-disciplinary individuals. In my opinion they all need to be involved from at least step 4 above. If that sounds lengthy or expensive then I put it to you that you have never felt the true monetary cost of badly executed ideas.

Delivery of disappointing product isn’t delivery at all, as far as I’m concerned.

So get everyone’s input from as early as possible. Together we are stronger.

Mission Teams

Ideally you’d organise quarterly Mission Teams, to focus on the Product Objectives delivered in step 2 above. These would convene at the start of each quarter (or just ahead of it) and disband at the end. They’d be made up of everyone involved in meeting the quarter’s objective(s): Stakeholders, designers, tech lead & engineers, copywriters (if you have them), etc. These should meet each week, but it’s a large group so the agenda for each meeting should be clean and simple:

• What we did
• What’s happening now
• What’s happening next
• What help we need

Some Mission Teams will run in parallel (depending on your squad sizes) — and some people will necessarily sit on more than one Mission Team, so don’t forget to be kind to your upstream (see below).

Don’t Talk Tech!

Tempting though it is, leave out all tech implementation talk until Tech Planning — that’s step 10! 😱

If you start fantasising about EventBridge rules or GraphQL schemata before that, you have stopped listening to the Needs and started listening to yourselves.

To be clear: I’m suggesting (perhaps somewhat controversially) that your engineers are involved all the way from step 4 “Problem Statements to address” thru to and including step 9 “Sprint Planning” without even the merest whisper of an implementational thought.

You need to keep the focus on The Thing until the very last possible moment — when engineering starts.

Read THIS to find out how we got to consistent user feedback of “It Just Works!” by avoiding talking tech at planning meetings!

Be Kind to your Upstream

Stakeholder / Expert fatigue

Delightful product delivery relies on innovative solutions from multidisciplinary teams. Read that again.

These multidisciplinary teams necessarily include business experts — Head of Credit, Marketing Managers, and so on. Plot twist: these people also have their own day jobs. Delightful company though the Mission Team is, these people would probably rather be putting out their own fires than helping you drag fresh wood onto your own.

If you only have one tech squad, the stakeholders and experts can probably fit your needs in their diaries OK. Two tech squads — it’s OKish so long as these tech squads work in different business areas. Three or more tech squads? It’s starting to get difficult now, and what you absolutely cannot afford is either to burn out your business experts or to make them resent your demands on their time.

So for this reason — THINK TWICE before you go to scale tech. Is your upstream ready? (Answer: probably not.)

Keeping the backlog fed

Somewhere between “Product is running so far behind that we always run out of stories” and “Product is running so far ahead that by the time we work on the story, the needs are out of date” lies the sweet spot of “just-in-time planning”. This subject in itself is a book on the Lost Art of Alchemy, perched atop a shrine of improbable marble inside the unicorn farm I’m already describing here.

Mixing in the need for experiments, prototypes and evaluations just shows what a precise and crucial skillset this is.

This is the Technical Product Management magic that needs to take place continuously through the life of the project. Every project is different, every team is different. If you want my direct advice on how to manage this on your own particular unicorn farm then you’ll need to hire me. Details at the end.

Technical Attitude

Primarily I’m a technologist, and yet I’ve talked at some length above about what needs to happen with anything but technology. “You lot need to march to my tune! Behold my beautiful glass house! Oh.”

But there is also a massive debt of duty on the tech team and its leadership. I will explain this here after a bit of context:

The Big Picture

Perhaps a little late in this article, I will explain to you here the simplest version of the trick I aim to pull off when I join an organisation in need of delivery improvement. It’s in two parts:

1. Get the organisation into a position where it thinks in terms of Product Culture and becomes a fizzing ideas factory for innovative, exciting product needs.
2. Line up a tech team which knows how to service these needs in a beautiful, sleek and (above all else) reliable fashion.

Everything I’ve written in this post so far has been centred around the first point. The art of achieving the second point is really where my day to day professional bread and butter is at [non-Brits: this means it’s my “main bag”] and it’s too big a subject to hang off the end of this article.

So let me summarise it briefly as follows:

Tech exists to deliver product, period.

It’s tech’s job to translate the visions into accessible (and indeed accessible) tech product. Your engineers are not there to be any of the following:

• the Department of Clever;
• a heavily-funded research project;
• pretending to be Facebook;
• (in the case of Open Source projects) the final Boss Fight in Mario’s Code Review Odyssey.

They’re there to deliver product. Their code needs to be Good Enough, and that’s all. Make sure they know this.

Tech does not dictate; it serves

If anybody outside tech is repeatedly saying “tech says no” or “tech are doing it this way instead” then the tail isn’t just wagging the dog; the tail has stolen the owner’s car and is driving the dog downtown for a beer, blindfolded.

The burden of explanation is on the expert

Yes, yes, tech is complicated, and deep, and inscrutable. Guess what, so is accounting, and marketing, and event planning, and — oh yes — running a freaking company.

So, tech folks: don’t treat non-tech people like Muggles. It’s our job in technology to make our processes and resources relevant to the wider business, and to explain them clearly and helpfully. Enough of the eye-rolling.

Tech leaders lead from the front

Possibly the most contentious point, particularly from the business point of view. The number of times I’ve been told stuff like “and then eventually you’ll be less hands-on” is… well, it’s happened a lot.

But here’s the truth: Tech leaders MUST lead from the front. Heads of Engineering must engineer. If you’re not in the code, then you’re irrelevant as a leader; what you are is (horror) a manager.

This is becoming even more acutely imperative as we hurl ourselves onwards into the world of Serverless — and in 2024 you really ought to be hurling yourselves onwards into the world of Serverless.

True Serverless and the dramatically decoupled, event-driven architectures which characterise the cleaner solutions in this space require such a granular knowledge of the various resources in your chosen cloud provider (e.g. AWS DynamoDB streams, Event Bridge rules, Step Functions’ States Language, SQS queue delay limits, etc) that in order to evaluate tech solutions, advise engineers and indeed LEAD the damn project, you have to have your hands dirty, every single day.

Conclusion

I’ve followed these principles for a number of years now and have supreme confidence in their efficacy. Naturally there are other approaches and many many other disciplines. I can hear the DDD gang sharpening their whiteboard markers as we speak.

But for me, working across projects as broad-ranging as fintech startups, central government, national health, SaaS providers, I can say with total honesty that when I’ve applied these values, the results have been extremely positive.

Good luck on your own particular journey and with your own particular methods.

But I am right.

Author: Mark Henwood | Mark’s LinkedIn