54. What projects to prioritize, and which you should kill, in your startup
Watch on YouTube
Today I want to address a problem faced by many founders, prioritizing development projects in the face of conflicting opinions and pressures. Because resources are usually critically limited, you must narrowly focus your development resources. What are you going to build, and more importantly, what will not get built? The problem compounds when you are a non-technical founder/CEO, and your CTO, developers, investors, or others are pushing to prioritize specific projects about which you have doubts.
I recently advised two founders in this situation. One was pressured by their CTO and the other by a potential angel investor. In both cases, they wanted to re-implement third-party code they had licensed and which was performing adequately. These applications were core to their business but fairly commonplace with the same basic functionality available from multiple vendors. Writing their own version would be a significant undertaking.
It can be challenging for founders to push back against more technical team members because they hired them for precisely those missing skills. The trick is to avoid having a technical debate. Reframe the discussion in terms of business needs and priorities. The CTO often wants a more interesting development project. They may be working on essential but unexciting capabilities and wish to exercise their skills on a more challenging endeavor.
Start the discussion by looking at your options in the context of the company’s limited development resources. It is usually a zero-sum situation where every effort displaces something else. Typically, there are many projects on the roadmap which are absolutely essential to your growth.
What Not to Build
In many cases, the project others are advocating is more of a “nice to have.” The company can function well with the existing solution, and the version you implement would not radically improve your customers’ experience.
In the case of the investor advocating for the project, they thought that developing the application would increase the company’s value. I disagree. If the code is not unique and substantially superior to the alternatives, it is simply another source of technical debt you need to continually maintain when you could have allowed it to remain someone else’s problem.
Just because some application is core to your business is not enough reason to build it internally. Consider a marketplace startup. The company’s unique aspects and value drivers are probably the kinds of parties on both sides of the market and how you enable new types of transactions. The requirements for marketplace software to enable buyers and sellers to register and list goods and services are relatively standard. Marketplace software is a commodity, and many vendors sell excellent and mature solutions you can buy off the shelf.
What to Build
When prioritizing development projects, my first approach is to eliminate everything I possibly can, then rank order the ones left over.
Build things that you can’t get otherwise and that you can’t function without. They might be unobtainable because nobody created them before, they are all proprietary and not for sale, or their pricing unavoidably breaks your business model.
Build things that embody your unique business insight. These are the kinds of capabilities to may be able to patent or technical innovations that create a significant barrier to entry for your competitors.
Build things that create a ten times improvement in user experience. Early on, you will almost always find high-impact low hanging fruit. Make sure you have addressed all of those opportunities before considering anything that will have only modest impacts.
None of these analyses depend on the technical aspects of the alternative solutions but only on the impact on the company and benefit to your users. That should be your north star in prioritizing development efforts and almost all other decisions as well.
