I generally prefer writing on medium (probably means I need to choose a new word press theme?). This article was first published on Medium in the Bootcamp publication. If you prefer that reader you can see the original here.
Cheap solutions: sometimes the problem isn’t the tech
Ian RoweMar 21 · 6 min readCuriosity, 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 promos. Worse, our promos couldn’t integrate with the other retail end point so 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 a 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.
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 the first two were accurate. This wasn’t about arrogance, it was about curiosity.
I kept my boss informed a long 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.
Questions, comments, feedback or you just want to nerd with a minor nerd (I know what APIs and M1 Chips are, but can’t code) leave a note here, message me on twitter, or email me.