When you have a team that is building a customer-facing product, it’s a common mistake to build your entire product team and associated processes around the application. In fact, you can model everything as a product, and extending that idea, your entire delivery pipeline can be also a product in its own right. But how can you do that? After all, the customer-facing application is something “real” and “tangible”, while delivery and processes are all about activities, flows, and tests. You can’t see it. In a way it’s like air, you can’t see it, but it doesn’t mean it’s not there and it’s just as real as your application or website.
Delivery-as-a-Product
As I mentioned before, you can approach anything “as a product”. How do you do that? Let’s remember some key principles of Product Management:
- Focus on user-centric needs and problems
- Use data and insights to design and prioritize your roadmap – don’t assume what your users want, test and validate
- Give preference to small & quick product iterations that allow you to quickly capture data and validate and extract new insights, as opposed to long and “waterfall” project executions
Your Delivery process is no different, and you can adapt these core tenets to continuously improve your delivery pipeline features, toolset, and processes. If you think about it, making continuous improvements to your delivery pipeline is kind of recursive in nature. As you expand that component, you’ll see that the known and trusted product-focused approach is very applicable indeed.
Who are your users and what are their needs?
That depends on the type of application, organization, and team you are part of. To give you an example, in my particular case, some of my delivery users and their needs are:
| Users | Needs / Problems to Solve |
|---|---|
| Marketing clients | – Product launches & content updates at any-time – Reported bugs and ASAP resolutions – Flexible release practices to support: on-demand releases, automated releases, scheduling, changing deadlines, etc. |
| Content Authors & Site Managers | – Ability to design the publishing process as a workflow: drafts, approvals, previews, etc. – DAM integrations – Content versioning – Scheduled content publishing |
| Application Developers & Engineers | – Allow teams & squads to work independently from each other if necessary and break code dependencies – Allow teams to deploy code without expensive and time-consuming orchestration activities with other teams. |
| Release Train Engineers, Project Managers & Product Owners | – Ability to plan releases and deploy without the headaches – Allow for easy rollback in case of issues – Ability to concurrently have multiple versions of content or code in Production – Ability to different types of deployment strategies: – Blue/green – Canary – Phased roll-out – User segmentation |
| Data & Analytics team | – Deploy pixels and tags on site any time without affecting others’ efforts, and without the need to schedule this along with the main code release. |
| Account Managers | – Whatever our processes and delivery approach are, we need to make sure the account has the ability to run reports: burn reports, projections, team capacity, and availability. Visibility at all times on projects, status and issues. |
| IT group | – Software patches and upgrades without affecting the day-to-day business – Refactoring of services |
There are many teams, and one customer-facing product, all of them want a piece of the cake, and they all believe they have the highest priority. Delivery-as-a-Product is a way to establish good practices and get rid of the madness.
Product Features for your Delivery
We have discussed how Delivery is a sort of abstract Product in a sense. There is no user/client-facing application or website, yet the capabilities and features of Delivery bring very real benefits (or pain points) to your user.
- Scheduled, automated, and unsupervised deployments
- Releases on demand
- Feature toggles / flags
- Dark-launches
- Content and component versioning
- Deployment strategies enablement
- Blue/green
- Canary
- Phased roll-out
- User segmentation
To name a few.
Make Decisions with Data & Insights
To make good decisions about where to concentrate your efforts, budget, and time, you need to rely on data and user feedback. That’s just the good practice in Product Management, you can’t let your own opinions or hunches drive where your Delivery practice is headed. You need to base it on real captured data.
The metrics that I’m mostly interested in are at the delivery pipeline level, and not so much at the task tracking level:
Deployment Frequency
- Number of releases through time – have they remained steady, increased, decreased?
- How many times do you do code releases? How long are your sprints? Do you need to be able to release more frequently?
- Do you have different groups trying to release updates at different times?
Deployment Speed and Optimization
- Quantify the time spent in different activities throughout your delivery pipeline – how much time does your team spend testing and validating a release? how much time does it take to move code and content between environments (i.e., STG -> UAT -> PROD)?
Deployment Nature
- Type of releases – has the nature of releases remained the same or changed? How so?
- How many stakeholders do you have in terms of pushing updates to your customer-facing product? Do they compete with each other? Track and document how many times you have faced orchestration issues.
- What type of testing is done throughout the release process? unit testing, integration, smoke, regression? How much time does the team spend on each one of those? Are there opportunities to automate any of this?
Issues & Problems
- Quantify, track and document the number of issues related to deployment tasks – can you identify a common type of issue that could be solved through automation?
- Track and document issues that happened after a Production launch, are they easy to roll back? How many times has this happened? How many times a month/year?
- When you need to collaborate with other teams, can you quantify the challenges? Are there any improvements you could do to make everything easier to share?
That should give you a good idea of the type of questions you should be asking yourself and your team, and part of optimizing your “Delivery-as-a-Product” is to adjust your practices and tools to be able to capture the data that is needed to answer those questions.
How do you capture that data?
A mix of qualitative and quantitative metrics:
- User surveys
- Meeting/interviews
- Application insights
- Delivery pipeline-specific metrics
- Retrospectives & post-mortem meetings
- SRE & monitoring
Who is your “Delivery” Product team?
The application / customer-facing product usually gets all the love. But your Delivery team, the one that makes it possible to deploy any day, any time, with little headaches, is the one that enables the “Product” approach. Ask yourselves, what good is it if your application team can deploy rarely, and many weeks/months pass in between releases? The whole idea of a product focus is that you can iterate quickly – prioritize, develop, deploy, capture data, learn, repeat… Without this team, that goal is unachievable.
Your team is as varied as you would expect from any other team, typically composed of:
- Project managers & product owners – sometimes they take to form of highly technical PMs, technical architects, or tech leads.
- Back-end developers – scripts, integrations, and tools to build automation, CI/CD pipelines, etc.
- Front-end developers – development of admin tools with user-friendly interfaces to execute delivery tasks, scripts, track deployment status, etc
- DevOps & System Administrators – configuration of CI/CD tools, environments
- Release Managers – sometimes they take the form of Release Train Engineers, especially if you are working within the SAFe framework.
- Quality Assurance – testing, monitoring, and validation of scripts, tasks, delivery, testing automation, etc.
- Etc.
Budget & Capacity
Finally, I mentioned before how the customer-facing product typically gets all if not all the love. In this case, love means an investment of time and money. How budgets are defined and assigned to each group is out of the scope of this blog post, as it depends on many variables that make each organization unique. But if you are faced with the challenge or task of needing to make the business case to invest money in your Delivery solution and practices, I want to make a few recommendations:
Demonstrate improvements with business KPIs -> cost and time efficiencies
Not everyone understands the efforts that are needed to implement an efficient and high-quality agile release process, but everyone understands time/money savings and reducing issues/bugs.
Make it a best practice to capture data right from the start, and constantly monitor your changes and improvements in the form of “before/after” reports. Personally, I have managed many times to justify new hires and team roles, as well as licenses for new products, tools, and frameworks.
Remember, the more efficient your delivery process is, it means you can truly focus on the customer-facing application and invest more budget to customer/client valued features.
Dedicated Product Team
Don’t leave your Delivery & Deployment practices as an after-thought. They are just as important as your customer-facing application team. They might play a different role within your organization, but they are still key to the success of your Product and business. If you are in a position of structuring your entire Technology team, make sure you design and structure your Delivery team with the same care and detail you do your core Product team.
