The CI/CD of Product
In the Software or Technology DevOps world, the term CI/CD is commonplace. What CI/CD means in that world is continuous integration (CI) and continuous deployment (CD). This means that when there is a change, proper procedures and steps are put in place in order to automate much of what needs to be done between ‘I have some code’ and ‘the code is production ready’. In the product management world, we may be dealing with code, or we may not, but we have our own form of CI/CD.
Welcome to the world of continuous innovation and continuous delivery. Of course, this probably sounds like I’m sprinkling some nice acronyms onto what product managers are responsible for everyday, but I believe that there can be a more refined process to how product goes through the product CI/CD pipeline. Below, I’ll touch on what it means to innovate and discover features or products that resonate with customers and help your product succeed within the marketplace, then I’ll follow-up with what I believe an ideal delivery workflow to that customer and marketplace looks like.
Innovation
Before we rush into what continuous innovation means, let’s dive a little deeper into what innovation means for products. Innovation can be seen as the continuous spark that is delivered through the features of your product that your puts a smile on our consumer’s face. How vague is that right? Let’s turn to Merriam Webster dictionary for all you more logical individuals:
According to their website:
Definition of innovation:
1: a new idea, method, or device
2: the introduction of something new
Let’s simplify and combine this dictionary definition with my definition of innovation: ‘A New Spark’
So how do companies typically find this new ‘spark’? Through the companies that I’ve had the pleasure of consulting to and working for, I have seen it come in the form of a huge product backlog, and some method of capture that can be an email inbox, or some sort of form, or the use of a product backlog grooming software. Once you have this list of items, then typically a product owner or manager will sort through the noise and find a few items that they feel will truly bring a spark to their product.
These items are then put through the ringer of executives, stakeholders, customers, sales, and marketing. It can take months before an idea is ready to be designed by an architect or technical lead. Sometimes as you’re prioritizing, other items will make their way up the backlog and become the next important item, and then something that has already made it halfway through the cave of flames will now get abandoned.
If the item is lucky enough to make it through these approvals, then it typically get’s developed in an agile fashion within the development team, and the ring of fire, and the game of squirrel continues.
The Proposal for Continuous Innovation
How do we take such a linear process and make it a more iterative and analytics driven one? The first is to embrace the idea of experimentation.
How many of the features of a product that is implemented become a resounding success like the product team or executives thought when the idea first came up? From my experience, that may be somewhere between 50–60% for large consumer products, and slightly higher for enterprise product, since their cost-per-failure is typically higher. Even with a number like that, according to the Productboard State of Product Excellence Annual survey, 1 in 10 product teams actually have a process for measuring and evaluating the metrics and milestones used to measure the success or failure of a feature launch.
So let’s visualize. What does a feature release cycle typically look like?
If this doesn’t look like what you go through within your product organization, then please comment below and let me know where I have it wrong.
Now what is wrong with this type of cyclical release cycle?
There is the assumption even going into the alignment sessions that an idea is always a good one, and that it should be aligned fully in the beginning, with almost a guarantee for success because then with each release it’s then assumed that the success is automatic, and the next idea is then tackled, and the cycle continues.
The other assumption is that the PM and Executive Approval Board/Team understands the problem and solution and are the most fit to decide whether the solution gets the green light or not, so when there is an idea that is presented to the executive steering or approval board, that it addresses the customer’s concern and that it will indeed solve the problem. I’m a firm believer that the executive product and leadership team should never have to worry more than the strategic and business objectives that your roadmap aligns to, and where they’re executed…not the actual features themselves. The review sessions as well should be on how well the features performed, and how they tie back to the strategic and business goals for the company.
The difference when enabling the CI/CD of product is that before align, there is experiment and research, and after align, there is still experiment and research, and you guessed it, even after the release we are experimenting and researching. A release should never mark the final resting place of a feature. It’s okay to start small, experiment, and iterate.
Let’s take on an example. You’re the product manager of a SaaS application that has a complex data table that users typically sort through for information. The user’s are coming back to you with all kinds of different filters they would like to see. Based on what you know and how much a user typically uses this table, you find that adding such a feature would help bring value to your customers.
With CI/CD thinking at play, you want to promote innovative thinking within your team who are trained in what they do best. Innovation doesn’t come from one brain, it comes from many. As a Product Manager, you want to keep your product team close as possible when navigating a customer’s problem. This is inclusive of your tech lead, your UX/UI designer, and your product marketing manager, plus anyone else you find input valuable to the customer’s solution (some companies have customer advisory boards, and this is also a great time to bring up items such as this). You would then present the problem at a very high level, almost as a user story. :
‘Our users have complex scenarios that require them to be able to filter down our data table to address various questions that arise from these scenarios, so we need to find a way to help them navigate our tables more quickly so that they can be successful with our data output’
In addition to this, I highly recommend determining where your feature falls in terms of your overall Product:
Now as a Product Manager, you’ll have some solutions and ideas already based on your research and thinking, but at this point, back pocket that for now and focus on enabling your team’s vision and customer centric thinking.
‘This is our vision, our mission, and why we work on this product. We want to help our customers…so that they can…and be successful at…”
From there, draw up a blank word document, white board or collaboration space with the user problem statement, and encourage your product team for input. What you may have thought of as a hierarchical filtering table could turn out to be the need to be a simple search bar.
After you’ve ranked/bucketed/prioritized the solutions based on objectives, effort and customer value plus whatever other metrics your product team comes up with to measure success of this return on feature (ROF) for your customer, then determine how you’ll concentrically roll out this feature.
Taking On Continuous Delivery
In the yellow circle bellow, you should have a mix of mature and entry users that you know would be or are early adopters of new features that the product typically rolls out (some may just call these users ‘beta’ testers). This feedback will be critical to iterate on before rolling out the the blue, white, then back remaining rings of your customer and market base.
What you get at the end is a well-thought out solution that goes back to the drawing board with each concentric-ring release. With each step outside the ‘beta’ zone, you mature the feature and guide it’s development towards an optimal solution that your customers will love, and that’s what we PMs live for.
To determine how your delivery is going, you want to set success metrics or milestones for each concentric color. For Yellow, that may be get 50% of users to give positive feedback and 10% to give negative feedback on initial test. If that succeeds, then great, move on to the next ring of users. If it doesn’t, rally that team you had during the discovery/innovation phase, place the feedback and user research results on the board/screen, ask ‘what do you believe we should have changed to make it go in favor of our success metric’, and based off of this feedback, go through the CI/CD cycle once again with clear measures for success.
Hard Truth of Innovation and Delivery
Not every feature idea or even hours spent aligning, designing, thinking, meeting is going to be successful. That is why it is so critical during the Product CI/CD process to set clear guidelines and metrics for how you will experiment and decide. When was the last time you revisited a feature, maybe one that wasn’t so ‘hot’ and determined how successful it actually was? You worked on that feature for a reason right, and did you succeed at fulfilling what your thought was the reason or belief behind the feature?
With CI/CD, even if you failed, you’ll have a defined process for understanding where the failure happened, and not only that you did your best a mitigating risk by involving your core product team.
Every company has it’s own complexities, market size, target customer type…etc. but I’m under the belief that companies, no matter the industry, size, or target customer market, can benefit from Product CI/CD.
