There is a tendency with some teams to jump right on their keyboard and start banging out an application or feature when they hear about a new problem.
Some call this a bias for action, I call this a code-first environment that is running on the track with dogmatic blinders.
This is often most present with engineering-driven cultures, or those driven by an unbalanced bias for action. As they explain, the believe they will just rapidly iterate with customers until they discover what the customer wants.
Unfortunately, this tends to lead to Feature Factories where you keep throwing features into the application in search for something that leads to greater traction in the market place. You keep building more and more and release feature after feature, but you never really get to celebrate because there is always something else that you feel like you must deliver.
This happens because we don't really have a solid vision of what the customer needs. This results in frustrating the entire team because they never feel like they are done and question if they are heading in the right direction.
On the flip side, early on this can feel like a good partnership story with customers because you are rapidly trying their ideas, yet later they will be equally frustrated how long it takes to make a simple change and how you are no longer getting things done from their priority list.
Agile Product Development is an absolutely critical aspect of a healthy product company. The key is to recognize what agile actually solves and what it does not solve.
What agile is not. It is not an effective customer discovery technique. It is not a tool to be thrown at a potential problem in hopes of validating that you are solving a profitable market problem. It not a tool to be thrown at a verified problem to find a profitable market solution.
What agile is. It is a set of lose structured processes that help you effectively iterate within the confines of a verified solution to find the specific nuances of the solution to perfectly fit the tastes of your customer base.
The Grey Area
Early in a project you may believe you have a verified problem and validated solution and you feel comfortable beginning to iterate on the actual implementation. During this phase you may find small pivots about how to actually implement the solution. These are great uses of agile software development processes.
Other times you may find that your approach to the implementation creates a greater or alternative understanding of the problem or solution. In these cases where a substantial pivot is to be performed, you must step out of implementation mode and back into problem discovery and solution validation.
(Wait. You should read that last line one more time.)
Many entrepreneurs and product companies will fail to hold themselves accountable to this rule.
Often, low maturity organizations misunderstand the role of UX in their processes. Instead of using design as the leading edge of discovering the right product with customer discovery and low cost prototypes. The sole goal of UX is not to try to create pages or user interface designs moments before (or worse, at the same time) development gets their hands on it.
There are two main reasons for this:
- An inability to deal with idle hands.
- A failure to recognize proper action around sunk costs.
Once we get into a habit of being busy, it is hard for us to sit still for a moment. We feel like if we are not doing anything we are not making progress.
Stop. Breath. Think.
Not always do the answers come when we are in the middle of answering a problem. We need to listen to that whisper in our head which is doubting the current path. Generally that is your subconscious telling that a greater understanding of what to do next is formulating, but just not there yet.
You need to be patient and wait for it.
If you are in the middle of a sprint and you just want to finish the work as it was planned to refactor it slightly later, then great. If you think that a major shift is required then just stop. Break the sprint if you have to.
Just stop until you have the time to validate the path forward (generally with customers). Even if this means that developers will not be churning out code.
It is better to take a month off of building your product to ensure that you have a validated path forward than to keep coding yourself a month in the wrong direction. Net-net when you consider all of the future refactoring, code debt, etc. that will result from continuing to march in the wrong direction, you will find that stopping at time will actually get you going in the right direction forward.
Trust me, your team can always find other things to do. (Remember all of those minimally viable features that you previously put out? Remember all of that build automation and automated testing that they wanted to get to.)
If you feel like you are performing busy work and you don't understand why you are working on it, then ask. You may learn that a HiPPO decision is in play, or you may just not have been explained the importance of the work.
No one wants to be wasteful. We don't want to pay a lot of money buying things that we will not use. However, when we purchase something that we have not used, we will eventually throw it away.
You know, that smoothie machine that you bought with the best intentions for eating healthy? How long did you keep it? A couple years? Maybe longer if it was in a cupboard that you didn't look at often. Eventually, you will throw it away.
It might not be until you move or buy a new appliance and need the space, but eventually you'll throw away things you do not need. That is for something that you spent very little time on when you bought it. Maybe you looked around at similar devices to pick the right one, but you didn’t spend months on the purchase. You may have thought about what color you should get, but you didn't spend time picking out the mechanics of the machine. You didn't try different gear ratios, different metal types for the blades to get the perfect marriage of blending capability and easy care.
Contrast that with product development where spend tons of time on the idea and implementation. This creates a measurable affinity to wanting our investment to pay off. This is true even when it is clear that the original course of action is no longer valid.
You've been there, right? Around someone who wants to just keep plowing forward even when all the data says that it is time to pause? Was it you? It's been me at times for sure. We all do it. We want to try to salvage the original investment.
In other words, we cannot look past the sunk cost or we decide to believe that the sunk cost is an asset even when we can’t really find any measurable value in keeping it. (”What if the next customer wants the feature?”)
So what should we do? We need to challenge ourselves to see the opportunity to improve on the next iteration. The asset is not in the outcome, but in the education that came from creating the artifacts. We don't want to throw away investments for the sake of starting over, yet never double down when the data shows that it is time to pause or abandon a prior path.
If you find this is happening, refer back to the execution blueprint and ensure that you are separating your solution and action activities into distinct steps.
While on the topic of avoiding code-first approaches, what is the alternative? Soon I’ll unveil the ideal development loop framework for optimal ROI, or what I call the Execution Blueprint, yet for now the short story is to think of your build process as three sequential stage gates.
The first is the problem space stage gate. This is where you ensure that you are focused on a 10x problem and that you have identified latent demand. This is when customer discovery and problem discovery are performed. Think Problem Discovery
The second is the solution space stage gate. This is where you ensure that you have identified the optimal solution to solving the targeted problem. This is when you perform mock experiments, often with tools like Figma. Think Solution Validation
The third is the productization space stage gate. This is where you build the validated solution and deliver it to customers. It is also where you will develop a prototype of the product to validate any technical concerns that you may have. Think Product Delivery
Corrective Advice Recap
- Remember that agile is an effective means for product delivery, not customer discovery.
- Ensure that product strategy is market driven and customer validated.
- Keep your focus on 10x opportunities and give your bets time to play out.
- Pivots representing big bets should exit implementation mode and return to mock experience validation.
- Don't fall prey to sunk cost fallacies and don’t feel like having idle capacity is a cardinal sin. Grinding your way to success causes expensive feature bloat that net-net is negative ROI.
- Ensure you recognize when you should be in the Problem Space (Problem Discovery), the Solution Space (Solution Validation), and the Productization Space (Product Delivery)