Tools and Processes
In my last article, Revenge of the PMO, I shared my views on the product development process called SAFe (Scaled Agile Framework).
It was a bit of a departure from my normal areas of focus, and the article caused a considerable stir, with more than an order of magnitude more dialog via Twitter, LinkedIn and direct e-mails to me than I typically receive from my writing.
Most importantly, the article seemed to help people to think more about the relationship between the product development process and the culture and mindset of the organization.
This article is not about that particular process, or really any particular tool or process.
The reason for this article is that several people tried to argue that any process or tool can be used for good or for bad, and you can’t really blame the tool or process.
Moreover, several people pointed out that I’ve argued for many years that what’s most important is not the process but rather the culture, so why even waste the ink complaining about a process?
These two related points are extremely important to product teams, and I wanted to address them both, because I think these points undermine the efforts of many teams.
One of the things that makes this challenging is that there’s lots of different tools, methods and processes out there. Even if we keep the focus at tech product teams, we have tools for product managers, tools for designers and tools for engineers. We have processes and tools for managing objectives, managing roadmaps, managing projects, managing issues and of course managing the code and data that we use to build, deploy and run our products.
In my career, I have personally worked on tools and processes in all of these areas. I spent the first decade of my career as an engineer building tools for mainly engineering teams – some of these tools were straightforward, mostly agnostic tools like debuggers and source code analyzers, and some were much more intertwined with how the team works – like software configuration management and change management systems. Later the tools were more about underlying Internet infrastructure and scale.
But the common denominator in my career has been tools and methods for product development teams. I still love the tools, methods and product development process space, but that doesn’t mean that I love all tools, methods and product development processes.
The key is to realize that every tool, method or process is trying to help the intended user to do certain things more easily, and they usually also intentionally make it difficult to other things.
As an example, an area of active tool development right now is the OKR space. Now if you’re not interested in OKR’s then you wouldn’t want or need a tool, but if you are, then you may be considering one of the several tools available.
There are a number of principles behind the OKR technique and methodology – mainly around empowerment, alignment, transparency, and a focus on results. Just to focus on one of these for a moment, to support the principle of transparency, the tools make it much easier to search to see if any other product team anywhere in your company might be working on a specific objective. And most of the tools actually make it hard to not be transparent. To me this is a good thing. But to others, especially those that hold different views on leadership and empowerment, this might not be what they want.
Another example would be product roadmap tools. As with OKR’s, there are a range of tools out there, and some have better user experiences and some have features for larger teams and organizations, but the deeper issues have to do with what the creators believe makes a “good” roadmap.
I have seen several tools that are designed to make it easy to tally the requests from different stakeholders and from different customers or prospective customers, so that the product manager can make a “data-driven” decision on what the priority of the requested features should be.
If that’s how you want to determine what your team will work on, then these types of roadmap tools are helping you towards that end. However, if you believe as I do that this is exactly the wrong approach to coming up with winning products, then a team forced to use a tool like this will have to fight the tool in order to try to do good work.
I’ve just highlighted a couple examples from the product management tool space, but I could just as easily use examples from design or engineering.
The reason product development process is often such a religious topic is because that typically impacts everyone on the team, usually in fairly fundamental ways.
When teams first moved to Agile methods like Scrum, most had to dramatically accelerate their release cadence (e.g. from releasing quarterly to releasing every two weeks).
That’s a pretty significant change, impacting release planning, design, engineering, quality assurance, deployment, product marketing, and more. If you believe, as I do, that frequent small releases is much better for us and for our customers than big bang releases, then this is a good thing. If you don’t, then you probably just circumvented the process by doing what many companies did – which is to just do a little QA each sprint, but only actually release to customers every 5 or 6 sprints.
You can hopefully start to see how these various choices either support cultural values or work against them. With just the examples I used here, these choices impact team empowerment, transparency, innovation, and the importance of product quality and reliability.
Every product development process is predicated on some beliefs about teams and leadership and how to create value. But you can’t go by what the tool or process vendor’s marketing material tells you.
You have to look closely at what behaviors and activities the tool, method or process is actively encouraging, and which they are discouraging, and you need to be sure this is aligned with what you want for your team and your organization.
NOTE: Recently my friend Ken Norton published this excellent article on the same topic.
