4 Types of Dependencies that Kill
Maturing companies develop dependencies. Startups exploit them.
Thanks for reading the ProductFix newsletter. As always, if you find value in reading this please give me some love by liking and sharing with others. For Startup Advice, Growth Design, or Product Leader Coaching schedule a free discovery call now.
📰Article
Dependencies Kill
One of the beauties of a startup is its simplicity of focus. A well-run startup is hyper-focused on a specific customer problem. They get started with a small team that is focused on deeply understanding the problem and discovering solutions to it.
This focus is viewed as a unique enabler of success against incumbents.
Incumbents, however, tend to have deep established customer relationships, proven feature-rich product offerings, and substantially more revenue to allocate into additional R&D.
From a headcount perspective, incumbents may have 10x to 100x the number of employees working on a given product category than the startup does. From a numbers standpoint, the incumbents appear to have an insurmountable edge.
Yet we repeatedly see startups compete effectively against incumbents, stealing market share, and sometimes beating them entirely.
Example: CRM Product History
Consider Siebel Systems, founded in 1993, whose CRM came to quickly dominate their enterprise application category despite strong competition from ERP vendors and legacy providers like Act!. As their business grew, a startup named Salesforce.com was launched in 1999, that focused heavily on small to mid-sized business. They went public 5 years later and soon overtook Siebal to became the world’s leading CRM.
There were more startups to follow, notably Hubspot who got started in 2006. They are now a top 5 leading CRM player, primarily by following Salesforce.com’s original playbook of targeting small to mid-sized businesses.
We could look at these startups and say they were more focused but the much larger incumbents had the great advantages of having many more people dedicated to development and advancement of an existing business. We also know, it is easier to sell to existing customers, so how do the startups repeatedly come and take market share?
Dependencies Encumber Incumbents
From my perspective, it boils down to problems tackling dependencies. Dependencies can come in many forms but they all create a lack of agility that creates a crack for startups to maneuver in.
Let’s list a few of these that come up repeatedly.
1. Dependencies on Existing Customers
As your business grows it acquires more and more customer logos. You celebrate each new logo as a win and report this as a major testament to stakeholders of the successful growth of your business.
The problem with all of these customers you collect is that they start using your product for the specific value it had provided at a point in time. For you to continue acquiring new customers, you frequently need to continue enhancing your product. At times these enhancements may reduce the value of the product for existing customers.
Further, when prioritizing a roadmap for investment, existing customers will certainly be giving you a long list of ideas they want to be tackled. Do you invest in keeping existing customers happy or invest capabilities to acquire new customers?
When you have no customers, you can make radical changes to the existing product with no complaints. You don’t have to worry about preserving customer data, ensuring a smooth upward migration path to new capabilities. With each new customer you acquire, you have more and more inertia preventing you from making significant and rapid product improvements.
Deprecating and dropping support for capabilities in use, even if they provide limited benefit to your customer base as a whole, can sometimes be such a problem that you simply avoid doing it to keep your NPS scores up.
2. Dependencies on Existing Technology
When Salesforce.com launched they took advantage of a massive rising trend in software being delivered over the Internet. Siebel was left behind with their on-premise technology and customers that were less inclined to move quickly to the cloud.
So when Siebel had to make investment decisions, they naturally chose the quicker ROI found in enhancing existing technology architecture rather than the substantial new investment in an uncertain SaaS model with a return unknown years away.
Product teams are often stuck with technology decisions they made more than 5-10 years ago. Startups naturally won’t be faced with such legacy dependencies.
For example, let’s say 10 years ago you built a custom machine learning engine, which uniquely differentiated your solution. You invest considerably each year to sustain that engine, enhance it, and build on top of it.
However, today, you find that open source tools like Tensorflow, not only do what you need but provide additional value that is inconceivable on your home-grown engine without substantial investment. Do you replace 10 years of investment with this new technology? This will introduce quality risk and follow on conversion costs to your customers and take away from investing in other value-added work.
Another common challenge with older products is that they are constructed as a monolith. This makes it very difficult to make small changes rapidly limiting the ability to leverage modern continuous integration/continuous delivery. Is it worth it to invest to break up the monolith dependency into smaller services?
Startups, by contrast, get to choose the best technology and architectures available today.
3. Dependencies across Product Teams
As the business grows, so do the product development organizations that support them. A frequent trajectory is to start with a single product team then add additional product teams as they become larger than 7-9 people.
If you are focused and have just a single product, multiple product teams are now working on the same product. There are a number of techniques for identifying fracture planes that minimize the dependency between two or more product teams. However, it will still exist.
This type of dependency between product teams reducing their ability to be responsive and autonomous in their ability to execute. Dependencies cause delays waiting for assistance and negotiating interfaces that single product teams don’t deal with.
As the organization continues to grow, there may be many teams with dependency on each other. Let’s say you have one or more platform teams, multiple value-stream/product aligned teams that leverage those platforms, and specialist teams providing expert support. While each new team added feels incremental capacity and should be able to do more, they frequently result in more dependencies to negotiate that will bog down execution.
Lastly, most mature companies have well-established objective management practices. Whether this is MBOs, OKRs, or something else. As the number of product teams grows increasing dependencies, any objective management model can create tension where dependencies reside.
For example, let’s consider Salesforce.com as they have matured. They have added many new solutions beyond core CRM and commercialized their underlying Force.com core platform. Product Teams work on platform products now that service Force.com, Sales & Marketing horizontal products, and industry solutions like Financial Services, Manufacturing, and Government. If each of these value streams has its own objectives and, wherever dependencies exist, there is a likelihood that investment priorities will not be aligned.
4. Dependencies on Existing Business Model
Of all the dependencies to tackle, being held hostage by your existing business model is definitely one of the hardest to deal with. Hamilton Helmer, in his book 7 Powers, calls the startup business strategy against this “Counter-Positioning”.
In short, if your business is built to deliver value to customers and make money in a certain way, it can be difficult to change even in the face of an obviously better business model.
One example Helmer provides is Netflix versus Blockbuster. Blockbuster dominated the video rental market and made substantial profits off of late fees. Netflix created a mail-order subscription service with no late fees that started rapidly stealing market share. Despite not being as accessible, customers valued the no late fees model. Blockbuster was too late to mount a credible response.
Business models relate directly to the products and features that companies offer. Consider the freemium model employed by Zoom to gain qualified leads through broad market adoption. Every time Zoom gets free user signup, they are preventing other video conference services from selling their product. GoToMeeting has not built a business that can support millions of free users, so they only offer a short trial period. How can they possibly switch to freemium without incurring substantial new marketing costs and potentially losing some paid customers to free?
Lessons for Incumbents
Developing these dependencies should be seen as a nice problem to have. It means you have been successful and gotten past the early days of being a small startup with lots of uncertainty ahead.
However, they definitely create blind spots and slow down your business agility. The best practice is two-fold: (1) minimize dependencies whenever possible and (2) actively manage those that you do have.
This means that for issues like technology dependencies, you should be continually incrementally investing to remove and mitigate these. Do not wait until you hit some critical wall because then it will be more costly and the ROI will be harder to justify.
With regard to product team dependencies, it is critical to design your organization with dependencies in mind. Do not ignore them but instead enhance your products to be API based between teams and empower teams to make changes to other teams’ code.
Lessons for Startups
Do not be afraid to take on larger, deep-pocketed incumbents. Be aware of the dependencies they have earned as they grew and look for ways to take advantage of them. Most incumbents will view their large install base as a great strength, but to a customer with a problem, it just means they can’t possibly be as responsive to changing market dynamics and rapidly evolving needs as you.
I recall competing against Oracle many years ago as a small startup. As a PM I would speak to customers that used both of our products, and the customer told me they never met a PM from Oracle before. They were so glad to meet someone who had a direct impact on the product that listened, I gained a champion for my product.
As a startup, research your key competitors and think about what dependencies they may have that slow them down. Wherever possible, take advantage of those and keep moving swiftly as you learn. Your greatest advantage is your agility.
Conclusion
Dependencies are a fact of life. How you deal with them is key to whether you outperform or underperform your competition. In rapidly evolving competitive markets, it is critical to find every advantage possible. Be sure to learn and proactively manage for dependencies.
👍🏼Weekly Recommendations
Podcast: This Week in Startups by Jason Calacanis. Over 1000 episodes of anecdotes, experienced startup investing perspectives, and strong opinions. A must listen.
Youtube Presentation: Lean Product Development by Michael Fisher who was at Pivotal Labs at the time. This video is 3 years old but I think it does a great job of describing Lean Product Development.
Don’t be shy. Please hit the heart and comment to share your feedback. Beyond that, I advise startups, coach product leaders, and consult on your most sensitive growth projects. Schedule an appointment to discuss how I can help you and your organization get your product stride.