But when I stopped to think about it, I realized that maybe this happens more often than we realize when we create software. At a very high level, we take valid input in the form of business objectives, translate it to a set of projects and features that we think will achieve those business objectives, and then transform it into perfectly valid output in the form of software code. Perfectly valid, but not always useful.
Has this ever happened to your or your company? Not anything this egregious, certainly, but have there been times when the business owners looked at what was built and wondered what was lost in translation?
If this has ever happened to you, you’re not alone. Here’s how the process is supposed to work, using Agile terminology for illustration purposes:
1), 2), and 3) – formulating a business strategy – are usually the responsibility of senior management at most companies. 4), 5) and 6) are usually the responsibility of product management, project management, development, design, and QA (depending on the company, since not everyone has all those roles or defines them exactly the same way).
It’s interesting to note the wealth of literature and training and the universal expectation that senior managers should focus on steps 1, 2, and 3. MBA’s learn all about these things in business school. There are books and training courses and management seminars. Simply put, the ability to formulate and communicate strategy is a necessary part of being a senior manager.
Similarly, there’s a lot of literature, training, and awareness on steps 5) and 6). There is training and tools for Agile and other methodologies; there’s training for user-centered design and information architecture, there is training for project management, and so on.
But let’s consider step 4:
At many companies, it can get a little confusing as to who’s really responsible for step 4), where business goals calling for product enhancements translated into candidate projects, prioritized, and approved to go to to development. Is it the CTO/VP Engineering? Is it the Chief Product Officer/VP Product, if you have one? Is it the CMO/VP Marketing? Or is the responsibility shared across multiple people, perhaps formalized in the form of a Product Council? I’ve seen all of these models over the years, and then some. While some technical executives take this responsibility very seriously and do a very good job at it, in many companies (including ones I’ve worked at) it’s hit-or-miss, and ends up looking more like this:
Why does this happen? There are several reasons. The Vision and Mission may not be formalized at all. The Business Goals may be unclear or so numerous or distributed that it’s impossible to make sense of them. People rarely agree on project priority: getting marketing to agree with engineering that refactoring Service X into Services Y and Z is more important than an A|B testing platform can be difficult…and vice versa.
There are few accepted best practices for prioritizing step 4)—and as good an idea as the Product Council is, its success can be limited by the ability of the members serving on it to work well together, to put aside selfish interests, and put the company’s interests first. Sometime’s that’s too much to expect.
The point is not that we are incapable of translating business goals into software. Clearly that’s not true. But we can get better at it, and that’s what the Roadmap Integrity Process is designed to address. I’ll be writing more about that in future posts.
The takeaway? We’ve invested more into formulating business strategy and the best practices of building software than we have into figuring out how to accurately map one to the other. As as result, sometimes things are lost in translation.
Tweet this: @bill_bliss New post: When Business Goals Are Lost in Translation http://wp.me/p1pkik-1K #prodmgmt