Listening is more important than technology: a story for product managers
Cheap solutions: sometimes the problem isn’t the tech
Curiosity, listening, and building relationships with the smarties who do the actual work, understand the business, and deal with our product(s) have proven to be more useful than new tech, at least for me.
Segmenting promotions is straight forward: marketing, or sales, (or both) is able to deploy a promotion to a specific segment(s)(locations, brands, revenue x, product mix y, etc) of your distribution channel.
When I joined our org a couple years ago, we didn’t have this capacity. This story is about how we built it.
When I started, I learned that my product (a retail end-point) caused a bunch of manual labour for finance when we ran promotions. Worse, our promos couldn’t integrate with our other retail end point, so our promos also broke the customer experience³.
So I started asking around about promotions.
“Promotions take 6 months to code,” said marketing. “They always have”. Always meant something like the last 25 years.
“When you run a promo on that thing, it doesn’t work on your other thing, and we get yelled at by our customers. Please stop,” said our distributors’ employees.
“We can’t piss off any more distributors so we’re only doing network wide promos. They are expensive and don’t help us with individual distributor relationships,” said sales.
“Promotions on your product cause us a huge amount of manual work and leave room for error we aren’t comfortable with,” said Finance. “Please fix this.”
My product was new-ish, so at least it had only been breaking finance, and pissing off distributors for three or so years? Ugh.
Did the business want promotions to work differently? Would our distributors care?
“We wish we could target promotions to distributors,” said sales. “They would love that.”
“We wish we could deploy a promotion without using developers,” said marketing.
“We wish we could get to market faster,” said marketing and sales.
“We wish we could better control budgets, plan better, and be more flexible,” said everybody in not so many (or sometimes way more) words.
The problem, I was told, was our old technology. For a bunch of good reasons, our technology stack was (is) a complex series of on prem systems from the 90s and the oughts. We are in the middle of modernizing systems and delivery, but right now (and certainly two years ago) we have what we have.
Was technology the problem? What did our developers think?
Luckily, we had started our journey to Agile so I knew the right developers to check in with.
Was it even possible for our tech to segment promotions from the central system, providing more functionality to the business, aligning our end points, and fixing the problem my product caused for finance?
“I’ve always wondered why we didn’t do something like that years ago,” said the key dev for the system.
Turns out, they had wanted to do something like this for more than 10 years (maybe longer), but no one had asked them.
“It’d be pretty cool,” said the other.
“Does the business want something like this?” they asked.
Interesting. One more question.
Out of curiosity, how long would it take you to build?
“Including QA?”
“Yes, including QA.”
“Say six weeks to develop and six weeks to test, assuming we’re still doing other stuff, otherwise maybe four weeks total.”
A promotion took us 6 months to program. Creating a whole new promotion segmentation system would take 3 months on the outside.
From six months, to next day.
From developers required, to the business uploading a file.
From no segmentation, to whatever segmentation the business chose.
From a huge budget, to a targeted one.
From one promo at a time, to as many as you want at the same time (functionally, if not literally, for development nerds it caps out at 9999).
From annoyed finance, to happy finance.
There were limitations to how this would work, and it is nowhere near the functionality we are going to have after the (giant) modernization project. But, we could apply it to some of our most popular products across our network to create wins with distributors before the major project launched.
Let’s do it!
Maybe.
Talking to my boss, the devs, and others, there were three main blockers. The biggest was that we were modernizing our systems. There is nothing quite like making things better later to get in the way of making things better now.
- Biggest: We were (are) modernizing our central (and many other) systems. So there was no point because the project would be done in a year, and no other work could get in the way (fair).
- Flows From Biggest: The two devs and QA weren’t on my team and they own the major system at the heart of our modernization project. They must be too busy with the big project.
- Scope: Was I allowed to do this? It was a big change that impacted my product a bit and everything else a lot. The devs were not on my agile team and the system was not my system.
Ignoring my own scope, I focused on finding out if the first two were accurate. This wasn’t about arrogance, it was about curiosity.
I kept my boss informed along the way. My boss’s main concerns were: the major project, that I not take on random extra work to please finance, and to be realistic about changing the org. I was given a long rope. I was allowed to ask questions. If this wasn’t my thing, at least we would have the details to provide to/lobby the right person.
That sounded like a yes to me.
The first two blockers were assumptions, more reactions than reality. My own assumption was that neither these devs nor the QA had much work (yet). Talking directly to the developers and their incoming product owner cleared this up quickly.
Has the big project taken over your lives?
“It hasn’t hit us yet. We’re just waiting.”
Their work would come hard and heavy in a few months. In the meantime, the devs had been told not to do anything new on the system, so they weren’t doing much.
Suddenly, we had a prioritized item for their early backlog. It helped that the product owner and I had a good relationship. More importantly, we had a creative collaboration inspired directly by the devs, sales and marketing. The developers were excited to work on something they had influenced, was largely they’re own idea, and that the business was excited for.
The devs were terrific. They reached out to various people in marketing and operations to align on details they needed. I poked in now and then to connect, keep on track, minimize scope and swirl, but others really did all the work. As much as I’m writing the article, this new feature exists 100% because of other people.
Everyone did great work. We use this feature regularly and are adding a another product to it this summer.
this new feature exists 100% because of other people
As a Product Manager my job was to be curious, listen, and connect the right people. But let’s be real, other people (as always) had the best ideas, asked the most specific (best) questions, and did the hard work (coding, ops process, selling this to distributors, making marketing plans).
Sometimes it’s not the tech you need, it’s the people you have.
I’m just lucky to have helped.
