DevOps is more important than product management for startups
Building software can seem deceptively easy in the early days of a startup because small teams can get by without much process and structure. Communication, strategic alignment and collaboration between engineers can be effortless when you’ve only got a few people. As you grow, though, things get complicated. Strategy becomes difficult due to competing priorities, so you adopt prioritisation processes. Collaboration between engineers becomes onerous, so you split your team into smaller teams. New features fail to meet customer needs, so you invest in more upfront feature scoping. Usually, much of this becomes the responsibility of your first product manager. As crucial as product managers are to software companies, I think DevOps is more important, and you should invest in it first when facing these issues.
DevOps is the practice of operationalising how you deliver software through automation, process and instrumentation/analytics. Key aspects of DevOps include:
- Automated testing. Instead of manually testing the features of your product before every release, you can write tests in code and run them during the development process. With automation, you can mostly eliminate the burden of testing from the release process.
- Automated releases/continuous integration. Instead of manually compiling and deploying new code on a weekly, monthly, quarterly or irregular basis, you can develop automation that will deploy code to your customers in real-time.
- Product analytics and platform observability. You can measure your product’s performance in real-time through application logging and integration with analytics platforms. This data can then influence how you make decisions. For example, application logging can reveal bugs and platform performance issues before customers discover and report them. Similarly, product analytics tell you how customers use your product, influencing product prioritisation.
- Feature toggles enable your engineers to choose who can access individual features and product changes without delaying the integration of new code into your product. Using toggles means pushing new code out with automated releases but hiding new features until they are ready, enabling easy early adopter or A/B testing.
In aggregate, the foundations above enable tight feedback loops, which empower teams to make better decisions, move faster, and deliver tangible outcomes for the business. Before DevOps, you need to manually test, manually release, manually survey customers and wait for bug reports before you know if the feature you built solves the intended problem and doesn’t introduce new issues. After adopting DevOps, the time it takes to learn from previous decisions will reduce radically. You can move fast, easily pivot, and quickly learn how to make better decisions. In short, excellent DevOps practices solve many of the same problems that product management intends to solve. These technical foundations mean many teams won’t need a product manager urgently because engineers and designers are empowered to build, measure, and learn independently. Additionally, teams that still choose to work with a product manager won’t need micromanagement — they will retain much more autonomy than is otherwise possible without DevOps.
Product managers should embrace DevOps because it will help them to make better decisions, move more quickly, and operate from a higher vantage point (potentially overseeing multiple teams). A product manager empowered by continuous integration, automated testing, and product analytics can confidently encourage their team to move quickly without fear of failure. These operations reduce the damage potential of suboptimal decisions and implementation mistakes. DevOps implements the build, measure, and learn loop, making it possible to innovate through experimentation.
Both DevOps and product management seek to solve the following problems:
- Return on investment, impact of work, and outcome-centricity. Product management solves this by defining problems formally, guiding solution selection, modelling expected outcomes and specifying solutions. DevOps solves this problem by making it easy for engineers to ship minimum-viable products, develop iteratively, and measure the effectiveness of their work.
- Prioritisation. Product management solves this problem through centralised decision-making and stakeholder engagement. DevOps solves this problem by aligning teams to measurable outcomes and enabling rapid experimentation.
- Quality assurance. Product management solves this problem through oversight, manual test coordination and user testing. DevOps solves this problem with automated tests, feature toggles and continuous integration (which allows bug fixes to be deployed rapidly).
- Stakeholder management. Product managers solve this problem through meetings and outbound communication with internal and external stakeholders. DevOps addresses this with automated release notes/changelogs.
- Technical documentation. Product management prioritises and produces product documentation, while DevOps solves this through self-documenting code.
As you can see, you can solve many problems with either more product management or DevOps. As most companies scale, they will eventually adopt product management and DevOps. DevOps may be the best initial approach because it will keep engineers empowered to own the outcomes of their work for longer and will double as a fantastic foundation for future product management.
Privacy and terms
I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.
The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.