Everything Operations
These days, a lot is being said around operations; predominantly that is Design Operations and Developer Operations. Why is everything ‘operations’? Though, I guess the question might be: why not? Today’s tooling is more empowering than ever, allowing lone traders to bring up a new online business in less than a day. Internal to organisations, it allows employees to take the power back, put a stake in the ground and forge an identity that can unite the team. But underneath the label of operations, what is there really? Well ideally, a business, for one. Before I dive deeper, I want to take a higher level view of matters as they relate to product development & design.
The CEO of the Product
I’d like to talk about Product Management for a moment. And all herald the product manager! The modern saviour of business; loudest advocate for the customer; the all-seeing, all knowing leader. What is a product manager? Let’s take a very common view, and of course, who doesn’t like a Venn diagram?
Here the Product Manager is the intersection between the business, technology and design. But of course, the whole point of the product is to focus on your users. Let’s add another circle!
It strikes me that this model is very self-centred, and I’m not sure where this all stops--just one more circle? It will probably stop at the point the product manager is exhausted by all of the teams and responsibilities being piled up. I can see why people that subscribe to this view just end up in meetings and writing Jira tickets to preserve their sanity.
Putting the Customer at the centre
Instead of slowly developing a desire to cut our own ear off, let’s put the customer back at the centre of things, surrounding them with everyone that wants a piece.
Here we have a modern start-up, with a handful of people doing multiple jobs. But over time things grow and more people are needed to make a specific role out of what was once a ‘mindset’. Enter: the product manager. But before I add one more carefully crafted diagram, where does the product manager go? They, as sure as taxes, aren’t going at the centre of things, but they are part of the business, part of the team. Throw them into the mix, they’ll figure it out as that’s why they were employed (ps. don’t forget to make us money).
Interlude: The Company Lexicon
As specific roles like product manager begin to enter organisations, it’s often about this time where job titles become more important, especially the words being used to describe the role. Quite possibly other words pop up, like ‘design’ and ‘operations’, usually preceded by the phrase, “we need.” Or perhaps it was the product manager themselves that began that conversation given they are worldly-wise and have a good overview of matters. In the end, we hope, the whole company wants to design, develop and deliver value on behalf of the customer, while also creating a sustainable business.
Product Management - A reprise
If I were to redraw the first offending Venn diagram and bring a little more substance to it, and also bringing in a better sense of design and build, we might begin with something like this:
We still have that elusive singularity at the heart, and previously this was the product manager. In order to make that the customer, we must instead position the product manager within the business. But as I thought about this model, it struck me that the everything-design paradigm could be stretched somewhat, and given the way DevOps has grown in prominence, I could get that into this as well. The next step then being to extrapolate that model across other functions. But first…
Interlude: The Service Architecture
One of my go-to tools is the service blueprint. It’s an invaluable tool for visualisation but the power is in the research and conversation required to build it. If you’re not familiar with service blueprints, doing a quick search reveals this good example from Brandon Schauer:
There are a few main sections to the blueprint: The customer experience, the visible interactions with the service, the unseen workings of the service and the processes required to manage the service (this last one is the most forgotten during design). This blueprint can be applied to technical systems or products too where the UI and interaction design is the line of visibility, the APIs being the systems that govern the internal interactions. Where we’re talking technical and internal systems, the blueprint can be summarised as a general service architecture:
The above may seem a touch complicated, but the layers described map to the layers required to build a service or product as:
- Design (Components)
- Architecture (Systems)
- Operations (Infrastructure)
- Governance (Management)
Where data is obviously a concern--and by ‘data’ I mean the capturing and persistence of information that is of business interest--the layers of the service architecture must be built to facilitate that data exchange between users of the system and owners of the system.
The aim of presenting this information is to show that there is a general pattern that can be applied to the structure of a business and its various disciplines while still keeping the customer top of mind.
Keeping the customer at the centre
The final state needs to bring together the layers of the service, the focus on the customer, the design & operations aspects we’ve discussed, and of course, the product manager. Building out the model focusing on concentric circles, this might look like the following:
Here we have a clear delineation between functions and aspects of functions. We may or may not be aware of it, but there is definite design in each facet of the business. I’ve called out a few key pieces, but there are many. Looking at the diagram, a number of things jump out:
- The customer is central to this map -- and if the customer type changes, likely the activities underneath this map will too;
- Those closest to the customer are those designing -- be it adapting the organisation to cope with new demands in the market, or the evolution of the business model;
- The Executive team who are charged with governance exist to provide the medium in which everything else exists -- the strategic fabric of the business;
- The layers support each other and are dependent on each other but are not separate -- innovation is a team sport too, and innovation should be shared throughout many teams;
- It should be straightforward to see where the holes in the business are: business model design? Product Operations? Information Architecture?
- The product manager is not the centre of the universe.
Where there is a focus on operations as a way to empower people, that is obviously fantastic, until it’s not. Our teams, structures and systems do not operate in isolation and the dependencies may not be obvious but they are most definitely there. We are all ultimately fighting the same fight, but sometimes not in the same manner, with equal visibility on the goal or vision. Stopping to think about how our activities interact with those of others and what outcomes we all desire can only benefit ourselves and our colleagues.