How to Treat Operations Like a Product: Agile Process Design

Building and scaling a team is hard. As a leader of your company torn between sales, delivery, internal product development, and administrative operations—where does the time go to work on improving operations?

Sometimes it can feel like you’re just inching forward, unable to deploy your process updates until a few more business cycles have already passed. It’s frustrating.

In 2017, the digital age, the world moves definitively faster than it did 6 months, 1 year, or even just 5 years ago. The drive toward faster load times, shorter advertisements, and increased digital interactions limits our attention spans, interrupts our daily lives, and leaves me feeling hyper-aware of the passage of time.

I don’t think it’s a coincidence we all feel the pressure of time. We are caught in an inexorable acceleration towards the future, and this feeling is the byproduct of an age built on the speed of light.

Information moving at hyperspeed keeps us scrambling to stay on top of new developments in business and the world. It’s understandable if you’re frustrated that operations don’t adapt and grow as fast as you need them!

Keeping both your tasks and your team’s tasks organized is an ongoing and daily battle. Setting aside the time to refactor your operational workflows, build better processes, and deploy those to your team through training is always on the Maybe I’ll Get To This One Day list. It’s not for a lack of trying to get to it—it’s simply a huge investment each time. There has to be a better way—right?

At Facet, I’ve struggled with marrying the needs of growing our team, training our staff, and improving the quality and consistency of delivery for our services. It’s challenging, and—while I’ve been generally good at improving things as they’ve come up—we needed a new way to:

• Solve process problems iteratively,
• Manage new ideas for process improvements,
• Easily deploy process updates to our team with training baked-in,
• Quickly adapt to changes in the industry, and
• Maintain an audit trail of process changes.

Thinking about these requirements for process design, our experience with product design and product roadmapping started to bleed into solutions. Our perspective is admittedly tinted by past experience and perhaps limited, but in this case it is the crossover which has empowered our approach. Now, we’re fully embracing the practices and principles we already knew and loved:

• Agile
• Product Planning
• User Story Mapping
• Web Development Best Practices
  • Version Control
  • Automated Deployments
  • Maximum Code Reuse

Agile Process Design: Building Process-as-a-Product

In evaluating our process needs, it became increasingly apparent that our internal work processes at Facet are actually products.

We had simply not been thinking about them in that way to date, and once we made the shift to evaluating our process with all the best practices of product planning and development, everything clicked—and we were left with Agile Process Design.

Agile Process Design allows our processes to be:

• Easily approachable: intuitively easy to understand the flow and discuss updates to that process design.
• Easily adopted by staff.
• Easily updated with changes automatically delivered to staff.
• Easily audited for change history.
• Consistent across all subprocesses to ensure company-wide compliance and quality of work output.

Process Design with Product Planning & Story Mapping

Once we started down the path of designing process with the same best practices from our product planning experience, knowing where to start was easy—story mapping!

With User Story Mapping we have a visual map of our process with the following sections:

• Deprecated - Steps we no longer use or which have been replaced by automation.
• Current - Steps relating to our active process.
• Unscheduled - Planned improvements for our process tasks.

The great benefit of User Story Mapping is it gives us the 2-D space to spread out the process and tell the story of how we deliver value to our customers over time.

• At the top of the map, the blue cards cover major milestones, or segments, of our process for a given service or internal procedure.
• Yellow cards define the discrete steps within the phases of service delivery.
• White Cards are discrete Stories or Tasks that will be deployed as tickets to JIRA for staff to take up and complete.

To give you a real-world example of how the Process Map visually maps to phases of our services delivery, once a service hits a Maintenance phase (blue card), the steps within tend to cycle through over and over (yellow cards):

• Review requests with client
• Size and schedule delivery
• Report on progress

These cards are regularly deployed to various JIRA projects using scripts on a sprint-by-sprint basis and only to the projects that need it.

Now, the great thing is if that process changes, or we need an additional step in place, or we need to combine steps, our process improvements are agile.

Process-as-a-Product Allows Agile Process Improvements

Planning our process as products means any update to our process can be prioritized and scheduled for development just like all other projects.

Agile learnings can be organized in the backlog, discussed, and then deployed dependably across the entire organization leveraging Maximum Process Reusability.

Process Benefits from Maximum Process Reusability

Thinking of our processes as products means we look at how certain subprocesses, or tasks, can be reused across services delivery.

For instance, we regularly deliver User Story Mapping as a subprocess, but that subprocess doesn’t vary much from our larger Digital Strategy process to our Web Support process.

Standardizing the subprocesses in one central code repository with JIRA Task templates ensures the consistency of future deployments of our Digital Strategy processes and Web Support processes—ensuring a quality product delivery as we scale our team.

Process Debt

By implementing all of our processes as custom scripts and applications, it is now much easier to see manual processes for what they are—technical debt!

Process Debt, like Technical debt, is a concept that reflects the extra work that arises when someone uses a process that is easy to implement in the short run, instead of applying the best overall solution for repeated use across the organization.

We’ve had a habit of building one-off checklists and work assignments based on the specific and custom needs of our clients, but this has been prone to error as we’ve sometimes missed checkboxes and couldn’t contribute learnings back to Standard Operating Procedures for future work easily.

Now, with custom work-build scripts driving our processes, a process debt ticket can be registered for any task which was developed one-off for a customer. It will later be up to the Process Product Manager to prioritize development for automating that process, or at least codifying the JIRA task templates.

One of the most powerful conversations I now have with customers is centralized around this concept:

If we can’t reasonably automate a marketing or sales process for our customer, how will it ever scale?

As in code, so too in operations.

Work Tasks Are an Artifact of Process Design

Just as deployments are an artifact of development, so too should our work tasks be treated as an artifact of our process design.

Our goal is that the task’s execution is consistent and of high quality.

With JIRA tasks committed to our process git repo, we can iteratively update the JIRA task templates and deploy those with Atlassian CLI to our various projects.

Custom Development of Process Allows Ease of Deployment to Multiple Interfaces

While doing our initial research, we found some process management tools are simply document workflow solutions, and don’t necessarily deploy to all of the interfaces we need as digital marketers.

The challenge we face as digital marketers is we’re not talking about just deploying a process to one system, we manage many systems for various digital marketing campaigns.

Updating process, for us, means updating:    

• Various Google Spreadsheets and Google Docs
• Confluence
• JIRA Task Templates
• Notifying team members of any updates (Slack, JIRA comments on related tickets)

At the end of the day, you manage your standard operating procedures with the system that you can most easily update and that most dependably deploys updates to staff.

This is why so many companies retreat into simply using text documents—they quite simply are the easiest to update and it puts the onus of work on the staff.

But if your goal is automation and the progressive decoupling of responsibility from staff—then you need software that sits at the intersection of accessibility, the ability to track change history, and the ability to deploy to various interfaces.

[TL;DR]: Benefits Found with Process-as-a-Product

• Product roadmapping and iterative development of process.
• Version control and process history.
• Automated deployment of process.
• Iterative replacement of manual process with process automation.
• Maximized reusability of process.
• Clear documentation of process debt.
• Agile with our needs as a company.

What tools are you using to manage your processes and standard operating procedures? Let’s hear it in the comments.