Product-led growth (PLG) has been gaining a lot of traction in the world of agile software development. This go-to-market strategy works bottom-up and often combines self-service, freemium or open-source products to convince the direct end-user to try the product without the involvement of sales reps and eventually convert them when a feature or usage paywall is reached.
The reason why PLG is so tremendous in delivering successful products is because product development is a complex problem: data is incomplete, there are no right answers and the outcome is only clear in retrospect. For this category of problems, the best solutions come from anyone and will surface through experimentation. It’s why our industry puts so much emphasis on incremental solutions with short feedback loops and experimentation.
High-integrity commitments
Companies who try to compete with the best PLG companies will find themselves having to transform away from their familiar top-down approach. The Sillicon Valley Product Group, known for its books and workshops around product management, teaches how to shift from ouput-driven feature roadmaps to outcome-based roadmaps combined with high-integrity commitments.
This outcome-based roadmap gives the product team a problem to solve together with all the autonomy to get there. The benefit is that most ideas don’t work out; and with a roadmap that does not focus on the individual features you can easily pivot to something that your end-users do love. Now, of course, you still have a business to run and that means that some marketing campaigns, partnerships and contracts require certainty. This is where high-integrity commitments come to play.
High-integrity commitments are few and happen after the team has had some time to understand whether this solution works for the end-user and is technically feasible. By having few of these commitments you can focus on accomplishing the deadline and drop scope on other ideas when time makes that necessary.
Invest in cycle times
Popularised in Accelerate as one of the four key DevOps metrics, the cycle and change lead time measure how long it takes when teams starts to work, commit and deliver the value through a deployment. This metric improves as you invest in better review processes, optimised pipelines and robuust continuous deployments.
While cycle time improvements always benefit your team, time and time again I experience how teams reap the benefits when their deadline approaches. Polishing a feature, ironing out the kinks or pushing through that small rework because early feedback taught us that usability is not where it should be, I’ve observed the amount of PRs quadruple around deadlines and all the inefficiencies in your cycle time will create a bubble ready to pop.
In the beginning of my career, I witnessed first-hand as an IC how it feels to be waiting for a slow pipeline to finish - just to see it fail due to flakiness and you have to rerun it. It’s agony when you feel the clock ticking. Humans are not supposed to wait for machines, machines should be waiting for humans and not be the bottleneck.
Gettings hands-on
Below are some pointers to improve your cycle time.
Use empiricism. You will want to focus on bottlenecks to get the biggest benefit. Your best bet is an empirical approach where you improve transparency, inspect and adapt. Don’t believe that you need sophisticated automated metrics, gather some small data for a week or two weeks and start with that.
Reduce time of pipelines. The CI/CD pipeline is likely the easiest place to start because it's not a cultural change but simply a matter of allocating hours to do the technical work. While I’ll be the first to argue against premature optimisation, CI/CD pipelines are one of these places where optimising through heavy caching, parallellisation and other techniques is worth the hassle. You can also increase the allocated vCPUs when it makes sense - the additional cost is marginal to the opportunity cost of an engineer waiting. Finally, decoupling builds from deployments is beneficial to iterate faster on improvements and to keep the pipeline maintainable.
Reduce time of reviews. Reviews should be quick sanity checks, shared responsibility and a way to share knowledge. You can evaluate how your PRs get reviewed. Many nitpicks and code convention remarks? These should be automated through static analysis - machines are way better at that type of task. Regular design mistakes that require big reworks? Share designs before coding and ask for feedback. Recurrent remarks for junior or medior developers? Take half an hour and teach him. If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime.
Reduce time to review. The cultural changes such as long times before a PR gets reviewed are often the hardest. Have retrospectives and talk about why this matters and will benefit everyone. Encourage and shoutout the people who take the right actions.
Improve incrementally. Finally, start small and don’t try to improve everything at once. It’s easier to sell as you can continue to work on features in the meantime. You want to foster a culture of continuous improvements, quick bursts of improvements usually decline rapidly and you will notice you are back where you started in no time.
By following these pointers you can invest in your cycle time, fend off Murphy’s Law, and build trust within your organisation by reaching your commitments.
