How We Product
Writing a post about how we’re going about building Onefill — a product I’ve dedicated much of the last 12 months to — has filled me with an immense amount of pride. We have an awesome team and I am truly humbled to be part of it. We all understand that building a great product is ultimately about making hard decisions. And sometimes it’s about not making decisions at all. Here is one example of not making a decision that we wanted to share.
Background
Onefill is a fintech startup seeking to extend banks’ digital offering to e-commerce.
We’re adding value by extending the trust customers already have in their banks to making online shopping more secure. We’re also making it easier to not only complete a transaction from a mobile device, but to make the best financial decision while doing so. And to ensure our solution provides the best value to the customer, and places no demands on the merchant, we have zero merchant integration.
While we have systems in place to map and update a vast number of e-commerce destinations, it is impossible for us to map ALL stores. New online stores are popping up all the time, on top of the vast number already in existence, so we must accept that our customers will want — and will try — to visit sites that we don’t know about. We call these ‘non-mapped’ sites.
The Onefill product team
While we may not always agree, we try to build a genuine team environment where everyone’s input is sought. Our core team is Mat Rutherford, our UX lead, and Omar, our ex-chef now junior product manager. Our content maven Sally also joins in on many discussions (because she’s an online shopping expert … and really smart). As does our engineering team. That sounds like a lot of input, and it is. Great products are developed that way.
Making decisions while putting our key user groups first
We are developing a product that we sell to banks, who in turn provide the product to their customers. This means we have two key user groups and two voices to consider. Mat owns the voice of the end-user, the customer. I seek to represent our bank partners.
This typically results in three types of decisions:
- Easy ones — where agreement is reached quickly (e.g. we need settings, and they should be here).
- Harder but non-critical ones — where there is disagreement, but it’s impact is limited (e.g. should the settings page be red or green?).
- Really critical, hard ones — where there is disagreement, and it’s important. I’ll be giving you an example of one of these very soon.
As we have a pretty firm product vision (and did I mention an awesome team?), we are fortunate that 80% of decisions typically fall into the first category. Around 15% fall into the second category. It’s the 5% where the going gets tough and the tough get going. In my experience, these can not only break a product, they can break a team.
It would be great to get comments/thoughts on whether these numbers are the same as experienced by other teams.
Solving our problems. In the boxing ring.
Backed to our non-mapped sites issue.
Lining up in the UX corner is our UX lead, Mat. His position is simple (as all great UX is): we should block the user from going to non-mapped sites. If providing a secure experience is a key UVP, then we can’t stand behind that if users can visit any old site (it’s assumed here that ultimately users will come across sites that isn’t secure).
Lining up in the product corner is yours truly. My position is: we are positioning ourselves as trusted ‘partners’ on the e-commerce journey. We therefore cannot abandon customers when they go beyond our previously checked and mapped sites.
The luxury of time
Time is often something that product teams don’t have. But if you don’t have time, you will almost certainly be rushed into making bad decisions. If there is one takeaway from this experience, it is this: map out your product and user journey early. We were weeks ahead of committing resources and likely months ahead of having to make code decisions. If we had to make this decision under more time pressure, we would have come up with a very different set of outcomes … and a worse product.
What happened
Very early on, this issue around whether/not the Onefill user journey includes ‘non-mapped’ sites was raised in a wider team product discovery session. At the time, it was an issue identified and argued passionately over. The joint decision was made that for the first iteration, we would limit viewing of stores to those that were mapped or verified previously by Onefill. This offered a simpler first version and the opportunity to test one option before committing resources to a more intensive solution.
During the discovery session, it was agreed this was a decision we would re-visit. And re-visit we did. It became such a point of contention that we couldn’t schedule another meeting on the topic without fear of exasperation. Yet, it worked its way into nearly every product meeting we had. We knew we had to address it.
We sat down and reviewed customer journeys for each option, paying close attention to customer expectations and anticipated outcomes. We even tried to argue the other side to convince ourselves of its merits just to reach a consensus.
Ultimately, the most important thing during this period was that we kept our minds open, and didn’t commit to a decision. Mat and I respected each other’s corner and views. Ultimately, we realised that neither of our positions was good for the product and only by thinking beyond these positions would we reach the right solution.
This approach, which reflects the way we tend to work, was captured so well in a great blog about product process:
“Teams that fall in love with a problem have more successful outcomes than teams that fall in love with particular solutions.”
On reflection, we did fall in love with this problem. It might have been a strange kind of love, maybe even a little masochistic.
Our Eureka moment
While this decision was raw and sitting open, we were able to work around it. We also weren’t afraid to challenge each other’s thinking about it. During this open process, a new solution emerged: could we provide the customer with guidance around the security of the site, even if the site was unknown to Onefill? Using a lot of standard web measures, could we build an automated heuristic to help the customer make their own decision about whether/not to proceed based on the security of the site?
The answer was yes. And after some more thought and debate, we all agreed.
How we product
As a product designer, these are the challenges that get me out of bed in the morning. Not because they are the hard ones, but because they are the ones that necessitate teamwork and collaboration.
What makes working with our team so awesome?
- We don’t shy away from the hard challenges.
- We respect everyone’s opinion and views.
- We have patience.
- We can identify the hard decisions that will involve some deep thinking, and give ourselves the time to work out the right result.
It is humbling pleasure to work with them.
