The Feature Parity Trap
There is a common notion that goes something like this — I can build that better, or if only Product X could…
Listen, I get it. It is extremely tempting to rebuild an existing solution and make it “better.” It is literally the function of capitalism.
Slack did it. Lyft did it. Instagram did it.
I’ve done it three times in my career so far. Once when I acted as QA on the Product team working on building a Drive Up experience. Later, as a Product Manager, I inherited the roadmap for two very different technical products, but the essence was thematically similar.
MVP = feature parity with whatever product (in my case, the replacement of our enterprise CI/CD solution, and the building of a recruiting tool) we were trying to make better.
Here’s what I learned:
Don’t railroad your product by striving for feature parity
Users are used to interacting with a piece of technology a certain way to do a certain task. It is a fundamental truth of being human that we feel the most comfortable and authentic when we are surrounded by familiarity.
While seemingly practical from a marketing position and to build adoption, you will be inclined to have your product feel familiar to users. They expect your product to work the same as the other product they are more familiar with, EVEN WHEN they have gripes about that product. If you take away a noticeable but dysfunctional piece of a product, the people will speak and they will be pissed.
(Re)building a solution with a set of features as a starting point is not a good idea. Counterintuitively, it takes you out of the mindset that birthed the idea to replace the product in the first place. You will spend cycles striving for parity before you can even tackle arguably the important thing: differentiation.
Instead, ask questions
Product People are used to figuring out WHO their users are. It’s a necessary part of the gig. We give them cute names (personas). We start by articulating their needs and break them into user stories — “as a busy mother, I need to have someone else pick up my order”and validate the workflow with a basic design, and you end with some Jira stories about the general workflow that accomplishes a set of tasks.
But. Something interesting happens when you pull yourself out of the mindset of needs, and instead ask, “what are [persona]’s questions when they are doing X?”
The Pickup story
Target launched Order Pickup first, and I joined the team to build Drive Up in 2017. At the time, Target was behind the curve in providing this service, relative to other retailers like Walmart.
Fast forward to 2019 after chain-wide adoption on both Android and iOS platforms when we were tasked with a key missing use case to the experience—allowing someone else to pick up an order.
Our small team of Engineers, QA, Product, UX folks met at an off-site to begin approaching this problem. This session was led by our brilliant UX designer, Dan Carlson (side note: if you ever have a chance to work with him, you are damn lucky), and it was unlike any other project kickoffs that I had been a part of before.
We put 2 basic personas on a board—The order placer & The order picker-upper—and asked, “what are their questions?” After settling on some sick jams as our creative soundtrack (very important) we began scribbling questions with abandon.
It revealed a lot of problems we hadn’t considered yet. If we had honored the status quo of modeling our experience off of something else existing, we most certainly would have risked user friction as the starting point.
As an example, taking the Order Placer in mind, “what if I’m able to pick up my own order after all?” illicited a workflow where the user does not have to specify a designated picker-upper when they place the order, whereas before that question was considered, we might have forced this behavior in a way that did not allow for the use case the question produced.
In the end, we had a basic workflow that incorporated a MUCH more inclusive set of problems to be solved than where we started.
The process distilled (or tl;dr)
Articulate your personas (users) that need to complete tasks. You can start small (like we did), or come up with a comprehensive list depending on how much time you have.
Get your entire product squad out of the office and into a neutral space. This is very important. Changing scenery naturally unlocks creativity and puts people at ease. Plus…it is just more fun.
Each person on your team will have a unique perspective and bring different ideas to the table and they’re all good. Engineers will know aspects of the tech that are not currently being used or know what is technically possible. QA folks will have a keen awareness of the usability of the experience. UX will help keep the experience cohesive and clean. Product will have an understanding of users and their needs. You need all of these to build something great.
Ask the questions users might have
eg: When does [user] need to know information? Once you know when, you can start to imagine what information they need, and where they should find it.
Group them thematically
Find the overlapping questions between your users
NOW you can start solutioning. What are the ideas for how these questions can be answered?
Draw it up! Everyone. Literally translate these ideas into a pen on paper UI and compare them to others’. Unless you are a designer, they’re probably going to be janky and that is part of the fun.
Discuss and vote on the best ideas for solutions to these questions
Check for technical feasibility
Iterate on design and include the same group of people
Build that baby
Ship that baby and measure feedback
