Why & How to Prioritize Product Table Stakes Over Features
(3 Min Read) Why Meeting Minimum Requirements is Crucial for Product Success
As an Engineering Lead, I have numerous candid discussions with my product leaders on various topics, including product direction, user experience, impact, and the priority order of product features. It was easy for us to reach a consensus on all topics except feature prioritization.
For prioritization, we lean on some version of this framework. Starting with impact on business, followed by feature sizing, team staffing, time to market, etc. While this generally worked, sometimes it resulted in incorrect prioritization of the features.
It was incorrect because we had product table stakes tasks below other product feature in the implementation order. That's bad because breaking that order has led us to poor customer experience, product adoption, and engagement.
One thing we do now to avoid this is that during the prioritization exercise, we categorize all features into two sub-categories, i.e., product table stakes and user delight.
And then, we prioritize "table stakes" before prioritizing other features. It's simple and effective, and it works.
But why prioritize table stakes?
Let's look at the definition of table stakes.
Table stakes are the minimum requirements for a product to be competitive in the market or satisfy customer needs.
It would seem obvious now that meeting table stakes are a must whether you are building an external-facing product or for internal users.
So, why do people miss it?
My two-part theory is that either 1) they don't do the classification exercise listed above, or 2) if they do, they have a hard time classifying features as table stakes or not.
For #1, make classification exercise part of the process when building a product/feature. It's easy to get caught up in the excitement of creating something new and innovative. We can sometimes overlook the basics in a rush to bring our ideas to life. Making it a process prevents against it.
For #2, use a _simple_ framework as below to determine if a feature is table stakes or if user-delight.
Table stakes:
If it prevents the user from partially or fully interacting with the product.
It's in the area of security (authentication, end-to-end encryption, encryption at rest) and availability (99.9%, if not higher)
Suppose it prevents the user from getting the full benefit of the product. For example, a user can create content but can't publish it.
User-delight features
Everything else
It can be hard to distinguish between table stakes and user-delight features. Here is a quick quiz to help with applying the above framework.
Table Stakes or User Delight Feature Quiz!
The answers are at the bottom of the post. No peeking!!
Scenario: Assume you are building the first version of user notes WebApp. You have come up with the following list of features for version 0.1.
Categorize the following as table stakes (T) or user-delight(U). Scroll to the bottom for the answer.
Signup/Login button
Forgot password button
Create new notes
Share notes with colleagues
Enable multiple font sizes, image/video embedding, etc
Saving un-encrypted data on servers
Building IOS/Android app
Multiple user-collaboration functions
Before I share (my) answers, one final note around the above topic "who is responsible for ensuring the product meets this basic requirement"? And the answer is both Engineer and product. Remember, it's a team!
With that, let's look at the answers.
Answers:
1.T 2.D 3.T 4.D 5.D 6.T 7.D 8.D
How did you do? If you picked different answers, comment below and explain why.