For many years I’ve been responsible for setting up technology and software development processes, for our clients, and for our company. This includes all the different items you would typically associate with the SDLC (Software Development Lifecycle):
- Planning & estimations
- Requirements definition
- Managing the technical backlog
- CI/CD – continuous integration & continuous delivery
- Agile – setting up an Agile cadence: biweekly sprints, code-freezes, etc.
- Tools: JIRA, Confluence, Jenkins, etc.
- Automation and testing
The challenge with this approach, is that it is inherently tech-focused. The last thing you want to do is create silos within your team, as if Technology is the only one responsible and accountable for keeping that engine running smoothly. Meaning that other disciplines are safe to continue working with their own and familiar pipelines, and as soon as something makes it to the backlog, it’s a dev problem.
I’ve seen that engagement model far too many times, and it always take a little bit of effort to steer the different disciplines to be aligned on the overall process. You can check my post on how highly-collaborative teams make for great products and architectures.
For the last 2 or 3 years, I’ve been changing the approach and vision to be more Product-centric. This forces everyone to see the entire effort as a continuous, cross-discipline, high-collaboration pipeline. Inputs to the backlog come from all disciplines, prioritization is something that’s worked as a team, as well as coming up with solutions to existing problem scenarios is not something left to UX alone.
I’ve been doing this shift in a more organic way, in the day-to-day of the projects; but finally I decided to put it in a visual format, which always helps in aligning everybody into a common goal and approach.
Continuous Product Delivery
The diagram itself is pretty self-explanatory, and I’m sharing it so you can add it as an additional tool in your toolbox.
The key term here is “Continuous”. The Product pipeline is a never ending process of gathering insights, testing, data & analytics, and ideation, and using that same information to drive the product evolution through an iterative process.
A High-Collaborative & Inter-Disciplinary Approach
If the previous diagram didn’t make it clear enough how this was meant to represent an inter-disciplinary effort, compared to your usual (and antiquated) SDLC pipelines, hopefully this one will make it so.
Next to each one of the building blocks of the Product Pipeline, I have added the different disciplines that are usually associated to them. It’s not an exact science, the labels and teams might be different depending on your client or your company, but it should be close enough to be useful.
In this particular view of the diagram, what I want to call out is the “All” next to the Continuous Planning block. Although planning is usually associated to project managers, account people and business analysts, I wanted to make sure that this DOES NOT mean that nobody else is involved or accountable. In a highly-integrated team, ALL disciplines are responsible for setting up the vision of the product, the priorities, what the focus should be, and the roadmap.
Deliverables & Activities
Let’s take it up a notch – and add some typical deliverables and activities to the diagram. For me, this is one of the most useful views:
- It helps in aligning the disciplines at a high-level (think kickoff of any project)
- It clearly states some of the main activities and deliverables for each one fo the teams
- Shows how everyone is connected and the different dependencies (it only works if we collaborate as a team)
- Helps in drafting up RACIs
- And in an ongoing project/account, you can even use it to audit the health of the account. How many of these items/tasks are being done?
I use this diagram a lot. I use it as a checklist when I kickoff new projects, when I have to audit ongoing ones, and it’s also a good practice to keep this in mind in your day-to-day responsibilities. Check yourself and others on how they are contributing to a healthy development process.
A Healthy Product Backlog
Finally, I believe the unassuming Backlog deserves it’s own special focus. The Product Backlog is the lifeblood of the Continuous Product Pipeline. It’s the glue that ties the vision, the priorities, the work, and how all disciplines work together in unison.
The backlog is made up of many items, and these items follow a lifecycle that should closely represent the higher-level product lifecycle. The different teams and disciplines interact with the backlog depending on which state those items are in.
For instance – if Item A is still in it’s infancy, hence it’s just an unvalidated idea in the backlog, it’s probably going to be a responsibility of Strategy, MarSci or UX to take it and run the required tasks to Validate it’s a valuable and feasible idea. Once validated, they’ll move that item to the “Test & Validated” task. Once it’s “Validated”, Creative and/or Tech will take it to start adding the User Stories/Child Stories and adding the necessary scoping details to then move it to “Actionable”… and so forth.
It’s this shared backlog, the common set of items that matures as it goes through the pipeline and product iterations, that makes it a highly-collaborative, highly-aligned process. It’s the team’s responsibility to make sure the product keeps a healthy and well nurtured backlog at all times.
