How Agile Discord Kills Startups
Lean evangelists such as Brant Cooper have warned that a lack of customer development creates a death spiral for startups. I fully subscribe to that viewpoint. What I want to warn about is an extension of this: If the work cadence of some parts of your Agile team is slow relative to your developer cadence, you still have the conditions for this death spiral. It may be counterintuitive, but having a high-performance developer team actually amplifies this problem. And it is most perilous if it’s your customer development function that runs behind.
Getting the cadence of your Agile organization’s major product development functions into harmony is a complex endeavor. Jonathan Berger has done some great initial work around the struggles of matching the Designer and Developer cadence. I have seen similar issues with matching the customer development cadence, a product management function. Startups that are very effective at customer development have a much better chance of feeding their designers and developers with product requirements that lead to product market fit. However, if customer development falls behind, it results in forcing product decisions that may appear reasonable but are actually very problematic. These conditions then grow into a runaway train that can devour your startup’s capital.
The Agile Cadence as a Runaway Train
Once software startups get past the initial validation phase and begin ramping up, there’s generally a huge emphasis on getting a strong developer team in place. This is for good reason — it’s a difficult but vital task. For this discussion, let’s assume your startup has raised seed funding and is somehow able to hire a developer team and starts building your product in earnest. The typical formula at this point is to have founders cover Sales, Marketing and Product Management roles as much as their background and experience allows. The hope is that the founders can fill these gaps until the next phase of scaling the business. Depending on the founder’s skill sets, most likely some of these areas will struggle but will be ok. However, unless you have a founder well versed in customer development, it is critical for this skill to be brought in before building out your developer team. Without this function, your startup will not understand who your ideal customers are and what products and features they really want. Since this is exactly what you want this new developer team to build, customer development is the horse in front of the cart.
Filling the Sprint Planning Gaps
Product decisions outside of customer development typically leverage readily-available priority rationals. In my experience, product roadmap priorities typically utilize the following rationales for why something should be built when good customer insights are lacking:
Alternate Product Priority Rationales
- It will provide for more feature parity with my competitors (Feature Gaps)
- A minority, but vocal number of customers are demanding it (Squeaky Wheels)
- It’s really wanted by Senior Management/Investors (Pet Projects)
- Marketing wants something as bait for lead generation (Optics)
- Sales needs it to close a deal in the pipeline (Feature Gaps)
- Product Management has a feeling it will work (Gut Instincts)
- It was drummed up to keep a specific resource type/skill occupied (Utilization)
These are in no particular order, although #7 is the most obviously problematic. However, anything listed in #1–6 can easily create conditions for more of #7.
I don’t have the data to back this claim, but the empirical evidence is strong that in most organizations, the above prioritization rationales drive far more product decisions than do real data-backed customer insights. In many cases, it may simply be a matter of a weak customer development function. But even if you emphasize that function, you may not be safe. High-functioning Agile organizations create rapid designer and developer cadence that constantly need fed product decisions. As a result, they have an insatiable appetite for product priorities with each sprint cycle. The further behind your customer development cadence is at enabling insightful product decisions, the more likely your sprints will become filled with requirements validated only by the above alternate rationale list.
Iterating into Product and Resource Bloat
Here’s a common scenario that plays out into the situation I’m warning against:
Say you are the CEO of a web-based consumer product, and one of the roadmap items is to build an iOS app. You do have data that 30% of your users are using your website on mobile devices, so it’s reasonable that even more would prefer a native app experience. Plus, everybody knows mobile is where it’s at. Your site is responsive, so it’s not a terrible mobile experience, but not great either. You also have some features that you can add that’s only possible as a native mobile app. You even have demands from some of your vocal customers that they really want a mobile app. Your investors are pressing you about it as well. Everybody is in agreement — well, everybody except product management who says she’s not confident that your customers will use it. She would like more time to run some tests. Or worse, she already has run tests, but you challenge the poor results. You are suspicious of the test population profile or methodology. In reality, you probably question it because the results don’t align with your bias. So you decide there’s no reason to wait — you are a lean startup; if it doesn’t pan out, you kill it. Also, you will at least have learned something and you can simply prune it and move on.
Now you green-light your team to go about resourcing the effort. This includes finding skills for iOS development, mobile UI/UX design, mobile QA skills and hardware. Your team ramps up on understanding mobile app lifecycle management and Apple’s rules and processes. You begin realizing this isn’t a trivial investment, but it’s a needed one.
Buildout and Adoption
Several months or more pass, and you have your iOS app in the store. It’s not doing a whole lot, downloads and usage are little more than the original vocal customers. You debate internally whether it needs some iterations, or it’s just not what your general customers want right now. Maybe you built the wrong part of your feature set for the mobile use-case. Maybe you haven’t marketed it enough and it’s an awareness problem. Maybe it’s both. Or neither. Who knows — the explanations are all just opinions. So are you now actually going to allow pruning of your nascent iOS app? If yes, you are a rare bird in my experience. If no, then you are now committed. Additionally, there’s a good chance you’ve fallen into a full-blown sunk-cost fallacy loop. It doesn’t matter, either way, you just shortened the life expectancy of your last fundraising effort with this decision. And you’ve shortened it much more than the sunk costs spent to date. The burn of this decision is likely just getting started.
At this point, your best option in terms of capital preservation is to cut your losses. But think about what that involves; you must rip it all out. Not just the code that was built, but also any specialized resources that were brought in to build it. Good luck convincing your CTO/VP Engineering to lay off any iOS developers that cost a fortune to find and retain in the first place. So now instead of pruning, your organization will make this decision cost much more by finding additional work for these new, no longer needed resources just to retain your sunk costs. As a result, your developer team is even more likely to build things you don’t need. Both your product and your developer team now have identifiable bloat. A bloated developer team; what an amazing problem to have, given how difficult it is to staff them! Of course, your developer team is not bloated overall, it just no longer has the exact skills you need. Now, rinse and repeat this cycle, and you get the real-world acceleration of product and resource bloat.
You might argue that your organization would not have made such an ill-informed decision in the first place. Yet based on the millions of apps in the App Store with pitiful download numbers, you are indeed a rare find. Or more likely, you need to make a more honest assessment of your organization.
Scaling the Product Bloat
Product bloat often happens on a much more mundane scale, yet is just as destructive. Let’s say there’s a minor feature on the website that Sales really wants, as it makes for a great lead-gen topic. Product Management is coerced into adding it into the sprint (after all, if we don’t get more sales, we won’t have a startup eventually anyway). The PM is fully intending to rip it out when she is able to prove with analytics that nobody wants it. However, she just created a lot of work for herself and signed up for a debate she most assuredly will lose. In order to later take this feature away from Sales, she must prove with data to management that the reason nobody used this feature is because it is unwanted by your customers. Sales will question the root problem; maybe it’s due to poor designed or implementation. Sales here is effectively the customer of the feature — it serves their purpose and they’ll fight for it. The product manager decides to let it go — she already has so much on her plate. She has to pick her battles. This one no longer has a good emotional ROI.
Now let’s say that this new ‘optics’ feature for Sales adds about 5% to your overall life-cycle maintenance. This is due to things like additional test case execution, knowledge base upkeep, and coding impact considerations. That may seem ok until you realize you’ve added 9 more of those types of features over the last quarter. Now your product is 50% bulkier than it was a quarter ago. Usually, this bloat creep goes largely unnoticed. What you will notice however is that your developers seem to need a lot more time than they used to for rolling out similar features.
In general, the product pruning that would help reduce this bloat is a difficult exercise to make happen with any regular cadence. This is true even when there’s no debate involved. In startups, you are almost always trying to focus on things that will make a near-term difference, and it’s hard to make the case that pruning efforts fit that qualification.
Defending Against Product Bloat
The best defense against unwanted feature bloat in your product is to get really good at customer development as an organization. In the meantime, implement some checks and balances against bloat. Here’s a list of things to do, in order of priority:
1 Establish Customer Development Early. Build out your resources and processes early on that enable informed product decisions. Startups are so focused on building out the developer team, they can neglect what’s needed to effectively utilize that team.
2 Prune Early and Often. Make product pruning a regular activity. Set the minimum usage threshold metrics for pruning, and stick to them. How critical this activity to your capital preservation cannot be overstated.
3 It’s OK to Bench Your Superstars. Don’t allow resource utilization to drive product decisions and sprint planning. If developer resources that you value are not immediately on priority items, it’s better to have them do nothing than create product bloat. Have them tackle technical debt. Or refactor code. Or have them on an indefinite hackathon if necessary. Or even better, go talk to your customers. Just don’t create work for them that will ultimately accelerate your product and resource bloat.