When Business Goals Are Lost in Translation

by Bill Bliss on March 1, 2011

in Aligning All Investments,Featured

A picture floated around the Internet a few years ago; perhaps you’ve seen it.  I know when I saw it, I got a good chuckle at the time.

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:

How Projects Should Work

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:

Candidate Projects

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:

How Projects Often Work

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

{ 4 comments… read them below or add one }

Jeffrey Vocell March 11, 2011 at 7:57 am

Great post, Bill.

I’ve seen the Candidate Project responsibility fall under Business Development as well, in the early stages of product creation / development. Although I’m not sure that’s ideal – it can work.

Switching gears for a moments, I think this happens far too often with existing projects in addition to new projects. All too often product vision, or a market factor of “future selling” results in communications not being in sync. That could likely be a whole series of blog posts because it goes throughout the hierarchy of mid-level personnel to senior management.



Bill Bliss March 11, 2011 at 8:59 am

Thanks Jeffrey!

In my experience, there are two kinds of bizdev people. The ones that live to get the deal done, and the ones who really care that the deal is successful and structure it accordingly – or pass on it altogether if it won’t be. Sadly, the latter are far more rare than the former. :-( Sounds like a good idea for a future blog post.

I’ve never been in a company where Business Development was responsible for prioritizing / approving projects. I think in most companies they are aren’t held accountable for the success of the project, as I alluded to, but if they are, you’re right it could work.

Regarding existing projects — I think I know what you are talking about, but just to double check… Are you referring to when the project requirements (or the promises made to customers) changes after the project is in flight, but no one informs the people responsible for building it?


Jeffrey Vocell March 14, 2011 at 3:17 pm

Hi Bill,

Sorry for my late response – there was a birth in the family and that took me away from the computer for a few days.

Anyhow, regarding the Business Development topic – I guess I was trying to say that they play a key role in coming up with candidate projects, but not necessarily having the final approval or authority on these projects.

And to answer your question about existing projects, yes that is kind of what I was referring to. More on the side of future selling a vision that is unattainable, at least within a short time frame (i.e. next release that already has requirements and is 3/4 done with development efforts). Large sales usually involved multiple tiers of people which leads to important product or vision details being lost in translation.


Bill Bliss March 14, 2011 at 10:28 pm

No worries Jeffrey, it sounds like you have your priorities straight. :-)

I have seen that phenomenon before. It can be a tough problem to fix.

The easiest way to do it is to have the most senior product person talk to the most senior sales person and explain why it’s disruptive to both the team and to customers and to nip it in the bud.

However, sometimes that doesn’t work or it’s not possible. Escalation is the next step.

If that doesn’t work, then it’s time to play hardball. Most product teams, in an effort to be “team players,” inadvertently enable this bad behavior by scrambling and pulling a rabbit out of a hat, time after time. This just reinforces the bad behavior.

One way to call someone on it is to force an unpleasant either/or tradeoff. Say “OK, we can do X, or Y, but we can’t do both by date D.” Consider X to be the superset of what was originally agreed to, and Y is some entirely different thing, but high-profile. Management is not expecting to have to choose between X and Y, they thought they were getting both. By forcing them to make a tradeoff they weren’t expecting to make, it calls attention to WHY they were asked to do so.

Timing is critical, and you have to pick your battle carefully, but I’ve tried it before, and it works.


Leave a Comment

Previous post:

Next post: