Client Requests vs Product/Platform Strategy
Weeknotes 4: June 15–19, 2020
One of the most exciting things about working with the Digital Oversight team at Transport is that we’re not building a product, per se. Rather, we’re building a platform that can be leveraged by many different programs, and their many different users.
I’ve always been interested in systems and patterns, so this is right up my alley! When I was a developer, I used to jokingly call myself lazy: I was always looking for reusable components or patterns so we didn’t have to keep building the same thing over and over again. Really, it wasn’t about not wanting to do the work, it was about investing in doing it well the first time, and not duplicating work and introducing inconsistencies/inefficiencies. But it was just easier to say “I only want to do this once.”
The trick of course is recognizing that one size doesn’t fit all, and specific circumstances and priorities mean that clients value different things. When you’re an agency doing one-off work for clients, you give them what they want.
But if you’re building a product or a platform, there’s another factor at play. You’re not just creating this deliverable and calling it ‘done’, you’re laying a foundation for future work. Work that may not yet be elaborated or considered. This may mean that you spend more time making things configurable, so it can be scaled or extended at a later date. Some upfront investment will pay off over time.
Why’s this on my mind this week?
I was in conversations with two separate clients this week about onboarding onto our platform. In each case, they have unique requests that will require us to extend the platform a bit; it’s not so easy as supporting their particular content. It’s doable, but of course will require some custom work.
In some cases, these clients may be requesting features that are unique to them, and would not add value to other clients. So we could absolutely do this custom work, but we’re a small team, and that could postpone our ability to support other programs getting onboarded onto our platform. It may also mean our platform gets more bloated with features that aren’t applicable for all, or we may be solving a similar problem for different clients in different ways because that’s how they’ve asked for it. As well, if we’re only working with a single client at a time and delivering what they’re expecting, we may be missing the opportunity to be investing in a more robust solution that can meet the needs of future clients as well. We’re focusing on the trees, not the forest.
A lot of this comes down to funding. We have to balance what we deliver for a client [because it is what they asked for] and what we deliver to meet the needs of our broader client base, now and in the future.
When I joined the team to lead their research practice, I was quick to establish that I’m not only interested in doing research with existing clients. Rather, I’m interested in doing research with people who have this job to be done, regardless of their current solution. To dig beyond satisfaction with an existing tool to really understand those user needs, that are either shared across user groups, or distinct because of circumstances. This is the forward-looking discovery that can help us with our product strategy.
This allows us to anticipate the impact of decisions we make. If today’s client asks for something that we believe will be a net positive for future clients, we may be more willing to invest in it, rather than something that’s a unique requirement. It can also help us make the case for proposing solutions that this current client may not even be asking for, but we recognize it can address a bigger problem. One caveat: this assumes that we have control over our own roadmap, and we’re not just delivering on client requests. This can be scary for product teams, to tell people ‘no’ and risk that they’ll reject what you do have to offer. But this is where research and strategy can come in; we can work to understand the most important needs and ensure those are addressed in a superior fashion than alternatives, which allows us some space to not meet every request (thereby avoiding the product death cycle as described by David Bland)
I feel like these weeknotes are REAL vague — I’m sorry about that, because I suspect they’re of limited value to readers. Context matters! But it’s a good exercise for me to try to get some of these thoughts out of my head, and track them regularly. So here we go…
Originally published at https://medium.com on June 21, 2020.
