85: The agency trap
I’m writing about 100 things I’ve learned the hard way about product management. You can catch up on the previous entries if you like.
How can product management fit into an agency business model when requirements or specifications are often contractually set in stone by the client up-front? Spoiler alert: not easily
In this article #
Product company or agency?
I was chatting a product manager who was thinking of joining an agency, the kind that takes on projects to build products for their clients, which are typically in the public sector. We talked about the differences in approach between an agency business model and a product business model.
Janna Bastow has a great article (quick – go read it now) that illustrates the differences between an agency and a product company. I have adopted her turn of phrase, “the agency trap”, which is a neat and convenient shorthand.
The thrust of her article is that a company ostensibly trying to create and sell software products (many instances of the same product to a large market) should avoid acting like an agency by taking one-off custom contracts (a unique product for a single customer) for short-term revenue.
Our situation was different to Janna’s example because this company was deliberately set up to be solely an agency: there were no plans to switch to a product business model either in part or whole.
How then can a product manager add value in a business optimised for this type of project-based client work?
Handling overly constrained projects
To be clear, I’m going to propose some creative ways to make the best of a pretty terrible scenario. I don’t want anyone reading this out of context and thinking I’ve thrown my principles out the window.
If the client project / contract is already constrained and locked down and there’s little scope or client concern about user needs (“we just want an X that does A, B and C”), then there’s little to be gained by trying to crowbar product management into the process. A self-respecting product manager will rapidly lose motivation and go elsewhere.
Practice the delivery bit
Sometimes the client is specifically requesting a product manager on the project team, perhaps to tick a box1, even though they don’t actually need a product manager because of the way the contract is structured. In that situation, a slightly-better-than-worst approach could be to use a product manager that needs more experience in delivery.
I completely acknowledge that this would set the product manager a terrible example.
In a normal situation, a good product manager and their delivery team would continue learning from their users and adjusting the product in response throughout the build. But when the client just wants “an X that does A, B and C,” there’s so little room for manoeuvre. So instead, this would be more about the product manager practising the specific process of working through a product backlog efficiently with their team.
The massive assumption would be that the client has asked for the right things to satisfy the needs of their own users.2 While that’s very much on the client, the product manager would probably still feel a bit dirty to not question the underlying assumptions nor to validate the product iteratively as they were going along.
An alternative approach perhaps would be to use a pure Scrum product owner, teamed with a more experienced project manager / Scrum master, who would really be driving the show for this type of project. For the record, I don’t regard this as fully product management either.
What are we really trying to get good at?
Although working in this way would offend our product manager sensibilities, a dispassionate observer would say the game we’re really playing at this stage is to optimise the delivery in three ways:
- (When the client spec is clear) How can we deliver exactly what the client has specified as efficiently and profitably as possible, to a good level of quality?
- (When the client spec is vague) How can we deliver something as efficiently and profitably as possible that the client will agree satisfies their contract? Or in worst case, will have minimal grounds to sue us for breach of contract?
- How do we get the product in front of the client as frequently as possible to minimise the divergence between what we’re delivering and what the client is expecting? And how can we use this as a form of tacit (or explicit) ongoing client acceptance so that there’s no big bunfight on completion of the contract?
And if there are lot of client projects with vague outcomes kicking around, how do we help the sales team at the agency to clarify desired client outcomes / outputs / deliverables before committing the company to a vague contract?
Without wanting to sound like a broken record (but I’m going to regardless), optimising a process that yields a crappy outcome in this way may create superficial aesthetic improvement, but ultimately doesn’t alter the status quo.3
Actual product management opportunities
I can see at least two opportunities for product management to fit in at an agency.
1. Mindful outsourcing of product function
The first is when the client is mindfully outsourcing their product management function to you. In other words, the client:
- wants the agency to facilitate a collaborative discovery -> alpha (prototyping) -> beta -> live -> handover process;
- is not being prescriptive of the solution, instead leaving that up to the agency’s delivery team to figure out;
- is open-minded enough to accept that their initial bets / assumptions / hunches about the problem, users and context may turn out to be inaccurate;
- would regard it a successful outcome for the team to come back after discovery or alpha and recommend not to proceed further, based on their findings, to avoid future sunk costs.
In this situation, the product manager and delivery team can explore the problem and solution spaces freely with users, and ultimately deliver an initial production version of a product that delivers value to users. Then they hand over everything to the client: the code base; designs; supporting research; product strategy; and recommendations for future iterations of the product. Some agencies will even transition the team itself to the client.
2. Apply product principles to the agency
The second is to apply product management principles to the services the agency itself. How can the agency become more attuned to its clients’ needs, work more efficiently and scale its business faster than it grows its costs?
These prompts may help:
Strategy #
What is the agency’s mission?
What’s their endgame?
How would they know they’ve ultimately succeeded?
Portfolio and service design #
What user / buyer problems does your organisation currently solve with its services?
How well does your organisation’s services portfolio match up with actual user / buyer needs?
Where are the gaps?
Where are the missed opportunities / underserved user needs?
Which are the most / least profitable types of service / project / client?
How consistent a user / buyer experience is the current service portfolio?
Which offerings need to be joined up to add more value?
Which ones should be simplified?
Which offerings should be retired?
What adjacent user / buyer problems could your organisation use its existing assets / experience / scale / people to solve?
Where are the opportunities to remove operational bottlenecks within your organisation from pre-sale to initial client contact to contract completion?
Scaling #
What would you need to change or suddenly get good at as a company if you wanted to work on 10x the number of client projects (profitably) than at present?
Final thoughts
There’s little scope for product management in a situation where everything to be delivered is contractually set in stone. Instead and if possible, product management should help an agency’s clients with the learning journey towards deciding whether and what to build, as well as what comes after.
Contentious? Let me know in the comments.
Notes #
- Such as when paying lip service to UK government’s service standard, which requires a multidisciplinary team to work on new services. In these scenarios, the client is typically a rogue government department that is trying to continue working in the same old terrible way they always have, oblivious to user needs, but still needs to give the pretence of conforming to the service standard to get their service live. By completely ignoring the intent of the service standard, their service is unlikely to pass the inevitable assessment, but that doesn’t stop them trying. ↩
- This is supremely unlikely (if we’re continuing to be honest with ourselves at this stage). ↩
- Or: you can’t polish a turd, but you can roll it in glitter. ↩
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”
— Lyndsay Denton
Jock Busuttil is a freelance head of product, product management coach and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, Twitter and LinkedIn.
Leave a Reply