The word ‘project’ is a given part of the vernacular of agencies and consultants. However, to shift focus from managing means to achieving outcomes, we need to start talking about product management, not projects.
In the world of agencies and consultancies, projects are sold almost by reflex. Almost everything is considered a project ruled by the eternal “iron triangle” of scope, time and budget. As consultants, we take pride in living within the confines of that trilateral space. We celebrate when deadlines are met and budgets unbroken. Yet we rarely stop and reflect over the change we’re making in the world. It would appear that the idea of the project is holding us back from achieving real outcomes.
This Article at a Glance
- Generally speaking, agencies and consultants work in projects as a matter of habit, rarely reflecting over why.
- Projects traditionally emphasize resource usage over outcomes and impact, which limits agencies when it comes to helping clients achieve goals that matter.
- Product management offers a different perspective and emphasizes customer impact over the constraints of the classical iron triangle of projects.
- Adopting tools and methods from product management forces consultants to consider the impact of their work:
- It encourages sharing responsibility for customer success.
- It recognizes the importance of UX and the entire customer experience as a condition of success.
- It doesn’t peddle assumptions as truths, instead recognizing the value of testing and prototyping.
- It fosters cross-functional collaboration leading to higher workplace satisfaction.
- It promotes a longer, life-cycle perspective of what you’ve built.
- You can start working product-oriented today by talking about customer success with your client, identify themes of customer value and cross-collaborate using Impact Mapping.
If All You Do Is Projects Then Everything Looks Like a … Project!
Many agencies and consultants welcomed agile practices when they rose into prominence and were eager to convince their customers of its merits. In many cases, it was for all the wrong reasons.
To many, agile became an argument and a way to get out of the classical triangle. By getting their clients to agree that scope was negotiable, agencies could prevent the overruns that still plague IT development and which eat all the margin. The consultant didn’t have to assume the risk that a certain item would take longer to build than was expected. Since many agencies traditionally use a cost-plus pricing model (hourly billing), and not value-based pricing, it was an incredible boon.
Now to be fair, cost estimations in IT projects are a hairy business. I know. I’ve spent a considerable part of my career trying to make sense of it. Agencies and consultants often operate with insufficient information. That makes estimations hard, if not impossible. Prominent agile thinkers even argue we should do away with estimations entirely.
“We’re outta here!”
In some cases, this development (though absolutely not the fault of agile practices) also greased the already slippery slope into taking on an inside-out perspective. That the agency’s job is about fulfilling requirements and once they’ve done that they’re “outta there.”
Whatever model you decided to use, the client will be left with the results of the labor. Whether that result delivers the intended benefits, or impact, is something many agencies don’t really care much about. Books closed. Invoice sent. On to the next challenge.
Usually, with the way this kind of work is priced and how the bidding goes, I’d say agencies are somewhat justified in their fire-and-forget mentality. Buyers consistently squeeze sellers over margins through forced bidding. Innovation and sustainability aren’t prioritized highly when the three walls of the iron triangle are closing up on you.
Many agencies haven’t explored the possibility of doing something else. They’ve never scoped value beyond the deliverables and never priced for it. Frequently, because they aren’t aware of it or they don’t know how.
Don’t you wish agencies and consultants could do more?
I think they can.
Reason One: A Product Mindset Makes an Agency Accountable for Customer Success
Imagine that when you start working on something, instead of focusing on your means, focus on the change you want to see in the world.
And so, as the focus of our work has changed from resource use optimization to delivering futures, so must our methods. The world of product management provides a set of methods we can adopt even for client work.
However, moving beyond the project and into the realm of products requires a different kind of thinking:
“The problem is that the product is not simply a set of features; the product is the way you talk about the product, it’s the way that you acquire customers, the sales process that you go through to actually close a customer, the experience that someone has when they’re going through that process. That’s all part of the product, at least in the customer’s mind.” – Jim Semick, CEO and cofounder of ProductPlan
As an agency working for a client, by taking a product perspective and adopting product management you put yourself in your client’s shoes. Their problems become your problems. You can communicate with a whole new degree of empathy and you build stronger customer relationships. From this new vantage point, you realize that just checking all the boxes and staying within the budget doesn’t count as success.
You get the urge to ask completely new questions:
- Why are we doing this?
- Why does that feature matter?
- Is there a better/faster/smarter way of accomplishing that?
- What problem does that solve, and for whom?
- Is this even useful?
- Why on earth would our customers pay for that?
Be Part of Bringing About the Change Your Client Wants to Make
To succeed, you need to be part of bringing about the change the client wants to make. You need to provide customer success. Or in other words, you need to help to ensure that your customer achieves their desired outcomes while using what you built for them.
With that in mind, the backlog items of the past are replaced by a clear guiding star and a roadmap for the broad steps to get there. The focus is now on outcomes, not inputs.
Reason Two: Product Management Does Not Treat User Experience Like Yet Another Requirement
Have you ever tried to write formal UX requirements? Ouch! They tend to either be too specific or wishy-washy. “The system should be easy to use” and similar clichés thrive in formal requirements documents.
On the other end of the spectrum are the usability engineering requirements that require formal usability testing with target metrics, such as specifying how long a task should take to complete. The testing is often done in a piecemeal manner at the component level that fails to account for the entire user experience.
With a product focus and in the world of product management, the users are jury, judge and executioner and in charge. A product that doesn’t assist, enthuse or delight its users will fail. UX and interaction design will become intrinsic to the process and done continuously.
User experience is a success metric and so, completion will hinge on getting the user experience right. Once again, checking boxes on a list just doesn’t cut it.
“A great vision should paint a picture of a brighter future for your customers. It’s not about you. It’s about them.” – Richard Banfield in Product Leadership
Reason Three: Unlike Traditional Project Plans, Product Roadmaps Don’t Have Us Pretend We Already Know Enough
While the agile movement has done much good to bring projects more in sync with reality, introducing agile contracts among other things, you can’t teach an elephant to surf.
Projects, even those confessing to be agile, assume we can define a set of requirements which somehow if fulfilled, lead to success. How detailed these requirements are and how much time is devoted to planning them out depends on your flavor of project managing.
Requirements Are Often Assumptions Served as Truth
What few questions are how those high-level requirements, aka ‘epics’, are formed. They’re usually the result of requirements analysis, which today consists of mapping out goals and constraints. Determining their validity is usually the purview of the requirements analyst along with project sponsors and the product owner. The team itself usually focuses on the backlog and as a result may just become very effective at solving the wrong problems, only faster.
With product management, the product vision is at the center and requirements (or their equivalent) are seen as a means to get there. Furthermore, they are the result of hypotheses – well-founded assumptions that we have good reasons to believe to be true. As a result, everyone’s focus will not be on delivering requirements as quickly as possible but to achieve the vision by means of validating assumptions through user research and prototyping.
“Because it’s a strategic document, what you want to convey in your roadmap is not a series of features or solutions but themes around the customer problems you intend to focus on and work on.” – Richard Banfield in Product Leadership
Reason Four: Product Focus Breaks Down Silos and Harmful Hierarchies
Regrettably, one of the human experiences that have shaped the way we think of working in projects is war. Many methods using for planning projects were indeed invented in the arms industries of the two world wars. In such an organization, uncertainty is hunted down like a mosquito in front of a flamethrower troop battalion.
The modern IT or digital marketing organization is radically different. Yet for decades it has let itself be ruled by ideas that were invented to solve a different breed of problems under very different circumstances. It has encouraged thinking in silos and in levels of command. It has led to businesses forming structures where tasks are handed out on an almost need-to-know basis and information flows one way.
You can put up with such strict rules if your job is about saving your country and the rest of the free world from an enemy like Nazi Germany. However, most modern corporations don’t have such world-saving ambitions. Higher shareholder value is usually as good as it gets. Employees are now asking for more.
Smart businesses have realized this and understood that they need to break down the silos and flatten hierarchies. Some argue that people are happier that way and think more creatively.
Now the good news is you don’t need to go all the way to a full-blown holacracy to enjoy some of these benefits. By adopting a product perspective and working cross-functional, you’ll see boosts in morale and output.
Use Impact Mapping to Foster Cross-Collaboration
In 2015 I set out to interview ten professionals within project and product management who were using a planning method called Impact Mapping. The idea was initially to deepen the understanding of how project and product managers think about this way of working. One of the somewhat surprising findings was that using Impact Mapping appears to make people happier at work.
Impact Mapping is a method that, in its original sense, was born long before IT companies adopted product-thinking on a broad scale. It posits that IT projects are performed to generate value, that the outcome is measurable and its only by engaging end users that said business value will materialize. As obvious as it may sound to you, this is still a relevant insight that many do not share.
One version of the method strongly encourages collaboration and is designed for product teams. It was those who had used the method this way, to structure meetings and involve people from all levels of the organization, that saw the strongest boost in morale. The key was that by focusing on a shared goal and enabling everyone to contribute, not only did ideas improve in quality, people also felt more fulfilled.
“The product leader’s job is to curate the right team, provide an environment for success, bring the user problems to them, and then facilitate conversations and help connect the dots so the whole team can design the solutions together.” – Richard Banfield, in Product Leadership
Reason Five: Products Exist in Lifecycles, Not As Single Shot Attempts
When all the code has been written and most of the bugs have been squashed, what remains is something that takes on a life of its own. Most of the software consultants and agencies deliver have a lifespan of years, sometimes decades. And, as we all know, everything needs maintenance.
By viewing your deliverables as products, the long-term perspective will be natural. Suddenly, through the lens of product management, life-cycle management is not just another project. It’s a natural step in the evolution of the product you just helped create. The reasons and the goals for that work are suddenly clear and natural. They are all there, part of the map that guided you where you are now.
When software is used to enable marketing, the need to think long-term is obvious. Everyone who’s ever tried digital marketing, well any kind of marketing, knows that it takes patience. It’s not a one-time project. It’s a marathon and a constant process consisting of assuming, evaluating and discarding ideas.
In other words, it’s a product.
“Dream in years; plan in months; evaluate in weeks; ship daily.” – DJ Patil, former US Chief Data Scientist
How to Go From Project to Product Today
If you’re eager to try product management, for your next project… er I mean product, try the following:
- Early on have a conversation with the client about what customer success looks like, for them and for their customers. Talk about ways you can help contribute to that. Think beyond checking boxes on the requirements sheet.
- Make a product roadmap instead of a traditional project plan.
- Identify a series of themes and try to view the backlog more like a roadmap, derive the critical assumptions and challenge them. The themes should be based on customer value. You can even frame technical requirements such as “legacy database interoperability” as “reducing the risk of interruptions (and the associated stress and time loss).” Everything you do will affect people, at some point.
- Try kicking off the entire endeavor with an Impact Mapping workshop and encourage the client to invite more than just the primary contact people. Map out the goal and the impacts. Use your customer insights to make hypotheses about end users (validate them later using user research) and turn their impacts in themes in your roadmap.
Moving from project management to product management isn’t something you do overnight. It takes a trusting client and an ambitious agency or consultancy to agree to work with roadmaps organized by themes and hypotheses over the familiar comfort of backlogs with requirements. Every project isn’t suitable to be a product either. And, honestly, why can’t we have a bit of both? Requirements aren’t all bad. Some things we do know, such as regulations. Other things are less known, such as end-user preferences.
Share Your Experiences
I don’t have all the answers to the questions I’ve probably given rise to. But I’d like to explore the possibilities with you. If you feel like trying this out in your business, write me. I’d love to be part of the conversation, hear your thoughts and even cover it on this blog.
You can also subscribe to our newsletter. This is a topic we will revisit to dig deeper into how you can bring product management to client services.
If you’re curious about product management as a practice, I recommend checking out one of the books below.
Are you ready to give up projects in your company and adopt products instead?
Let me know in the comments!