One trick to build better products, faster
How to build impactful features, not just more features
How many times have you come to the end of the day, or end of the week, and asked yourself the question:
“What was the point?”
Almost all modern teams now at least profess to be Agile in their approach to building product (God help you if you’re still making top-down decisions), meaning:
1. Building based on user feedback
2. Adapting to a changing context & as new feedback comes in
Unfortunately, far too many teams do not follow through with these principles in practice.
Instead, a culture of stress, overwork & rushed decision-making reigns, meaning Agile theory is discarded as soon as the first version of the product goes live.
Regardless of what we may believe about being customer-centric & adaptive, that belief rarely translates itself into action.
Instead, because we are stressed, overworked & rushing our decisions, we simply default to a metric of efficiency:
Our activity becomes focused on the pursuit of getting more done, at the expense of everything else, namely, having impact with our work.
We define more features.
We build up a backlog of more things to do.
We rush just to get through our endless to-do list of tasks.
And when a task is completed, when it’s launched, we blow a quick sigh of relief, and immediately start on the next thing on our list.
And, an often overlooked side-effect: Teams dehumanise our engineering teams, treating them like simply cogs in a wheel, there to execute and write code — any code — rather than thinking, feeling, autonomous individuals who can actively contribute to a company’s success.
Which is the point, I imagine, where you have stopped to ask yourself before:
“What was the point of it all?”
And you’re completely right. What is the point of it all if we don’t know the outcome of our work? If we don’t really know why we did what we did in the first place?
It makes absolutely no sense. No sense at all to simply get lots of things done without having a clear justification for why we did it in the first place.
Not only does it not make sense, but it’s downright dangerous. It is an existential threat to your business to be making decisions blind, with no genuine consideration for how to focus on building things that have impact, rather than just simply building more things.
It’s like going on a diet, but eating and exercising at random, whilst closing your eyes for a few months & hoping you come out skinny on the other side.
Why We Fail To See The Point
If you talk to anyone with half a brain, they would, in most cases, agree with the theoretical argument that it makes sense to understand precisely why we are going to do something before we actually do it.
To at least have a vague hypothesis of what you would expect to happen by doing a thing — building this feature instead of that feature, for example.
So why do we not see this fairly common sense argument manifest itself in reality?
In far too many teams, a culture of stress, overwork & presentee-ism (i.e. sitting at your desk looking busy) reigns.
Informal cultural norms, such as sitting at your desk until 6pm because everyone else does, regardless of how productive you are being and despite supposedly having “flexible working hours”, does not incentivise you to think strategically and to be more impactful with your work. Why should you, when you need to just sit there for 8 hours however good your work is?
Formal cultural norms, such as promotion based on hard work, who is in the office longer and most “dedicated” to the mission, literally encourage behaviour focused on getting more done (hard work), rather than having impact with their work (smart work).
And when team culture actively promotes a culture of hard work over smart work, almost always accompanied by a culture of stress, overwork & sitting-at-your-desk-all-day-looking-busy, it’s difficult to effectively challenge that.
And so, despite professing to follow Agile, which holds as one its central tenets the need to adapt according to customer needs & to focus on delivering high-impact value for those customers, teams simply stop thinking actively or strategically.
They are so overwhelmed with how much they they have to do (encouraged by their own internal beliefs that getting a lot done equates to a good week, which in turn are heavily influenced by external beliefs within company culture), that they are simply incapable of strategic, clear thinking.
And, thus, they focus on what is in front of them: A list of things to get done. And they measure their progress — and success — based on how many things on that list they get done each week.
(Again, to reiterate the point, this despite the fact that Agile theory and Agile methodologies, such as Scrum, warn explicitly against the trap of building for the sake of building.
Furthermore, although a Product Owner is theoretically the solution to the problem of prioritisation (i.e. focusing the team on only doing high-impact work), I believe that, because of the uncertainty of a startup, it should be the core activity of the entire team to explore, evaluate & execute what they do. Furthermore, if you either do not have a Product Owner, or the Product Owner cannot predict the future (which they cannot), then it is both dangerous and unrealistic to expect them to act as some sort of all-seeing Oracle.)
Why Agile Doesn’t Work Without The Right Culture
Quite simply, a change in culture is requires as a prerequisite for applying Agile theory, with the end goal that we wish to do impactful work and, ultimately, build a profitable business:
And that, specifically, that change in culture should manifest itself (based on my own experience in managing my own business & based on the scientific literature on productivity), in accordance with the following beliefs:
1. That great decisions make great products
2. That great decisions do not come from stressed, under-slept, unhealthy, busy minds
3. That, therefore, as a team, we must push ourselves to create calm, clear, happy minds
4. That only by fostering these principles can we collaborate effectively, gain high-impact insights, come up with the ideas that move us forward in leaps, rather than in stumbling baby steps
Yet how do we engender a cultural change to realign our team around creating impact, rather than simply looking busy or getting more done?
It’s very difficult. It’s why I wrote a book specifically on how to build successful products — and ultimately a successful business.
I believe we cannot truly succeed without rebuilding our foundations:
By transforming yourself in order to be more effective by cultivating the following traits:
1. To be robust, so we are better able to persevere through difficulty and failures
2. To be more mindful, so we are better able to see things clearly & rationally
3. To be better able to focus on what is truly important — what is essential — in making decisions
Making our teams value & encourage these values, so that teams can stop wasting their time on meaningless work, but actively foster highly effective work.
Making our process as Lean & Agile as possible so that we can adapt — thrive even — in the uncertainty that is inevitable with any new venture.
But making those changes requires a multi-faceted approach that requires perseverance and difficulty, so I will leave you with one specific strategy that is low effort, high impact.
One Strategy To Change Culture & Actually Be Agile
Although we cannot radically change the way our entire team operates, due to the complex, deeply ingrained habits of thought & action engendered by a team’s culture, we can make one specific change that can gradually nurture a culture focused on impactful work over efficient work.
Assuming your team follows some variation of the traditional to-do list, such as using a Kanban board to organise tasks, it requires a simple rethink of how those tasks are managed.
‘Done’ Does Not Mean Done
Most teams work with three or four columns:
1. Icebox: To store features that have been discussed or which may not be the right thing to build at the moment
2. Backlog: Tasks either defined or in the process of being defined. If you follow Scrum, then the Backlog may be broken down into specific sprints, depending on the size of the team and how far ahead your team plans
3. Work-in-Progress: What is currently being worked on
4. Done: A task that has been completed and is either being deployed or is deployed. T(here may even be a Review column to check code/design quality, but for the sake of example, I would like to just focus on the primary steps in a team’s product development process.)
The problem with this, as I stated at the start of this article, is that we still do not know what the outcome of our work is. We can see the output (e.g. we have launched feature x), but we cannot see how feature x was received by users — and whether it can be determined to be a success or failure.
One small change that will have an iterative, positive impact on your approach to product work is the simple tweak of your Kanban board, pulling out your ‘Icebox’ column and adding a final column called ‘Being Validated’:
1. Backlog: This should be a short list of tasks that are still to be discussed or that are already defined and ready to build. Any important features will come up in discussion regularly, so we have found it more effective to simply not have an ‘Icebox’ (an Icebox also encourages an emotional attachment to previous ideas that may no longer make sense in the changing context of your product, so we have found it better to simply start afresh each 1–2 weeks with ideas)
2. Work-in-Progress: What is currently being worked on
3. Done: A task that has been completed and is being reviewed & deployed (as we try to work on smaller tasks in a process of continuous delivery, we try to avoid writing complex code that would require a lot of time to review, but if you work on a more complex product, then it may make sense to add a Review column here)
4. Being Validated: Tasks are redefined as ‘experiments’ in this system (which I will explain below). Each experiment has a very clear hypothesis to answer, which is always in relation to the key metric we are trying to achieve in order to validate the current strategy we are working on. By tracking the result of our experiment, we can track whether we have answered that hypothesis, and therefore whether the experiment has been validated or not
Validating Experiments, Not Completing Tasks
The simple addition of the ‘Being Validated’ column takes seconds, but it does require, as a prerequisite, teams to define clearly what exactly we are trying to validate with each experiment.
Each task must therefore be defined as a clear experiment, taken from a template to encourage the adoption of this approach, with the following:
- Objective: A clear hypothesis statement as the title, in order to focus all the activities of the experiment on validating whether that statement is proved to be true or false. For example, if we believe that ‘feature x will increase revenue by 10%’, then, firstly, we need to ensure, as part of the experiment, we can actually track the impact of this change, but, secondly, what it does is ensure that we can actually know whether a feature was a success or failure (and decide what experiment to run next based on that information)
- Description: A description that requires specific, data-driven justifications that underpin the hypothesis statement. If, for example, we believe feature x will increase revenue by 10%, where did that ’10%’ come from. Results from previous experiments? Competitors? Psychological models? Although we will never be able to predict an outcome, we can get /better/ at predicting outcomes (thus helping us become more effective in determining what to work on — and why — in future experiments)
- Checklist: As everything we do as a squad is directed towards answering our hypothesis statement, all sub-tasks to make this experiment happen should be within the same card (it seems unimportant, but, again, it just relentlessly focuses the whole team on answering & reviewing the hypothesis, rather than just mindlessly getting a list of things done)
Although running this process as effectively as possible requires some cultural changes — such as one where we consider reviewing the results of our work as an essential part of our work, rather than just rushing over it — this simple change to your workflow will create incremental improvements in helping you be more impactful as a team.
There’s no silver bullet where you’re suddenly going to transform into an Agile, effective team. However, even if you are not running hypothesis-driven experiments with everything you do, which is unrealistic at the beginning, the simple existence of the ‘Being Validated’ column, as well as the adoption of the experiment template in some of your tasks, will at least get your team to start asking the right questions:
What was the outcome of that feature we built?
Why do we think we should build this feature over that?
What data do we have to support these decisions?
Is this really going to impact our revenue by 10%? Or are we just doing it because someone in Marketing asked us to?
The aim is to eventually shift your culture iteratively towards asking the right questions — ones focused on impactful work.
-
And if you want the full guide on how to change how you as an individual & a team do more impactful work, as well as the details of setting up a truly hypothesis-driven process, then please check out my new book, the first chapter of which you can download for free.
