The main focus for the ways of working I’ve been speaking about for years has been product. The goal of these ways of working is to make products that meet a real need for a real user in a meaningful way. The frameworks themselves – agile, lean startup, design thinking, lean ux, okr, et al – are the scaffolding that, if done well, can lead a team to achieving exactly that goal. As we all know building in those frameworks (to any extent) inside an organization can be extremely difficult. One way to overcome those challenges is to apply the methods to the implementation of those methods. In other words, instead of focusing on building a better product, those of us in positions of influence docs on building a better process.
Meeting real needs for real users
I realize this is a bit meta so let’s break it down into specifics. If we apply product thinking (a collective term for these methods) to implementing a new way of working we have to start with the need. In most organizations there is a drive for speed, agility and a responsiveness to the continuous change in customer behavior, technology and market forces. That’s our need.
Next we need to make sure this need exists for real “users.” In this case our target audience is internal – it is our product development teams, their stakeholders and the company’s leadership. We can interview these folks. We can hold retrospectives with them. We can analyze those results to come up with a current list of causes for a lack of agility, speed and responsiveness. We can also start to get a sense of which slice of our target audience should be our first focus.
How might we…build a better process?
Everyone’s favorite product idea brainstorm prompt can also be applied to changing how a team works. For example, we may ask, how might we ensure that a team always has the data it needs to make tactical day-to-day decisions, reducing decision-making time by 80%? We’re not necessarily going to build a product to do this. Instead, we, as influencers of how an organization works, may propose a change in process, way of working, policy or organizational design that we believe will enable the behavior change we’re seeking. We can continue to do this, generating a set of process hypotheses that may help us achieve our goals.
Experimenting with process hypotheses
Like any good hypothesis, product or process, we now need to test it. We determine what the riskiest part of the hypothesis is and then how to test it in the cheapest, fastest way possible. Perhaps we decided that to help the team make faster decisions we’re going to give everyone access to our analytics suite and ensure they get training on how to use it. Additional licenses are expensive though and training is also costly in various ways. What should we test first? Perhaps we should test whether the teams even want access to the analytics tool. We may then go about that by sending out a survey to all product development team members describing the tool, its benefits and what access to it would provide. We’d ask our colleagues to indicate not only interest in the tool but to commit to signing up for a date and time for their first training on it. Based on their answers we would then decide if this was a hypothesis worth pursuing.
Applying the process to the process
Change is hard and it’s risky, especially at scale. We can use the very same techniques we’re trying to implement to de-risk our products to our ways of working. The concepts of problem statement, target audience, behavior change and hypothesis translate perfectly to process changes. As you contemplate your next effort at improving ways of working consider de-risking it by using the actual tools you hope to see succeed. In so doing you’d actually be making the case for the benefits of these tools at the same time. Win win.