From Complex to Click: How We Revolutionized Mobile Coupon Creation
Picture this: Our solution engineers were drowning in work, spending countless hours coding mobile coupons while our client list kept growing. With Apple and Google Wallet gaining popularity, we needed to add even more functionality. Something had to give - our engineers were about to revolt!
The Challenge
The Plot Twist
Here's the kicker: We already had a mobile coupon product. The problem? It was about as user-friendly as assembly language. Clients couldn't create coupons without coding knowledge, and now we needed to add wallet integration. Talk about a perfect storm!
The Fun Part: Getting Creative
The product already existed. It was too complex for our clients to use since coding was required to output the coupons and the company needed to add the capability to save the coupons to Apple and Google Wallets.
The pain points were obvious from the beginning, however I still needed to do more user and customer research before starting the project. The user research was easy. Talk to the solution engineers within the company. I set up a series of 1:1s and group meetings. After gathering the input, I had a good sense of where the product needed to go.
It was now time for customer research. After speaking with several existing and potential clients, I was able to summarize the feedback and merge it with the competitive and user research I had already finished. Finding common themes was easy and I was able to quickly put the features and their benefits into nice, neat buckets.
The Monopoly Masterstroke
I had worked with the solution engineers before on other projects and knew telling them the prioritization could be a mess, so the Scrum Master and I came up with a different solution to get buy-in - Monopoly. After a quick ballpark estimation meeting with the developers, we had a rough concept of the level of effort for each feature. Next, we put together a Monopoly board of features with costs.
I gathered the participants (leaders and most vocal/influential) into a room, gave them money, discussed each feature and benefit, and explained the instructions. What happened next was magic. From a behavioral science standpoint, I was extremely interested to see if they would act in their own self interest or pool their money together.
They immediately started buying inexpensive features that mattered to them. It wasn’t long before they came to the conclusion they should start pooling their money together for some of the larger features and even bailed on their original self-interest purchases for the overall good of the product. In the end, they prioritized the features exactly as I did, but now, it was their idea and they were bought in.
Making It Happen
I took the prioritization, shared it with the stakeholders to complete the buy-in process and went to work on the product requirements document (PRD). I put together wireframes and worked with design to finalize the user interface. From there, a quick prototype was developed that we put in front of the solution engineers to smooth the rough edges of the user experience.
The only hurdles that remained were to develop, test and release. Overall, the process went smoothly with one exception. Google changing their API contracts without notification caused us a few issues. Luckily, the process we schemed for getting buy-in resulted in the solution engineers that were happy to resend the campaign with the updated coupons for Android. Additionally, the clients were thrilled they could make changes to the coupons themselves 24/7 which wasn’t possible before.
The Big Win
The results? We slashed coupon creation time by 75%! Our solution engineers could finally take vacation days without their phones blowing up, and clients could update their coupons 24/7 without needing to know what a semicolon was.
The Secret Sauce
The real MVP of this project wasn't the tech - it was the approach. By turning a potentially contentious prioritization process into a game, we got genuine buy-in from everyone involved. Sometimes the best solution isn't about the code at all - it's about getting people excited to solve problems together.
And hey, who knew Monopoly could be used for something other than destroying friendships?