I like products with “all the things.”
For months before the first iPhone was released, I was sure that I wasn't going to get one.
The rumors, and there were several, were constantly uninspiring.
- There was not going to be an easy way to have a favorites list
- It wasn't going to work with my corporate environment
- There was no cut & paste
I had been a long-time user of phone computers—often changing every 5-8 months when a new one came out.
I had the Nokia 9000 Communicator (seen in the1997 classic, The Saint with Val Kilmer).
And I owned every other one until that point, and after that. From Palm devices to Windows smartphones to Blackberry phones.
All because I liked a powerful device that had all the features. Not some broken-down, partially-complete new Apple iPhone.
So when I tell you that the trick to building a product that people can embrace and evangelize is to do one thing well, it may feel disingenuous. I get that.
The Introduction of a Minimum Viable Product
If you've been online in the last few years, you've seen tons of startups come and go.
With the rise of The Lean Startup, and the concept of a Minimum Viable Product (MVP), tons of folks have shared the same concept—do one thing well.
And you can see it all over Twitter and Facebook as images posted regularly. Here is one of my favorites.
The concept is simple. You want to build your MVPs incrementally, but consistently delivering value. Not just getting partially complete over time.
This is good stuff. I really like it. But when it comes to software products, it can often feel like every feature is needed. And the concepts of scooters and bikes and mopeds aren't year clearly defined in an existing market.
Additionally, the concept of an MVP (over the last few years) has often resulted in a “just push it out there and see what happens” approach to product development.
This has resulted in a lot of crap, a lot of disappointment, and a lot of bad habits adopted.
Your “One Thing” isn't a feature, it's an activity
If you interview 50 people that want to use, or plan to use, your software product, you'll get 50 “key features.” It's going to happen.
There will be overlaps, but trust me when I tell you, in the early phases of product development, everyone has directions they want you to head, and in each scenario, different features are required.
So the trick for you to do one thing well isn't to focus on features. It's to focus on a key activity.
This is what the iPhone got right for me in that first version.
In those days one of the biggest frustrations I had wasn't email, cutting and pasting, or anything related to apps. Simply, it was using my phone to do the basic phone things – like voicemail.
If I had 40 voicemail (something that was a common occurrence), I had no idea which one was important. I had no way to select a specific one to listen to it. I had to go thru every single one of them to find out if any were critical or from important people.
Additionally, if I was listening to a voicemail and wanted to return the call, I'd have to hope they left me a phone number or jump back into the list of missed calls.
And the new iPhone solved all those problems with native features in the OS that made the phone massively better than any other phone I had ever had (for phone calls).
All driven from the notion of listening to voicemail and returning calls. That was the activity that drove the innovation.
Quality comes from testing all the paths of that key activity
With the rise of a data-centric approach to product development, we've seen tons of instrumentation. Tons of data collection. Tons of metrics.
But we've not seen the same commitment to narrowed scopes of features that work together to help us with key activities.
More importantly, we've not seen the testing that ought to come with product development focused on activities.
I'm not talking about unit testing or integration testing. I'm talking about acceptance testing. Testing that walks down the variety of paths that a user takes in the main and supporting cases for the activity and goal they're pursuing.
Doing it Right – My Favorite Example
One of my favorite examples to point to, when it comes to activity-driven feature development, narrow-scoping, and critical testing is a WordPress plugin that's an extension for WooCommerce. Its focus is subscriptions.
Now, I know some people have gotten frustrated by the fact that they have to purchase both the Subscriptions extension and the Membership extension for WooCommerce to create a recurring payment for protecting content. They want it all wrapped up into a single solution.
But I disagree, for all the reasons listed above.
To build a successful subscriptions product, you need to focus on the key activity—charging a person a regular amount consistently over a regular period of time.
Now, if you've never thought about this space or how this would work, that sounds ridiculously narrow. I get it.
But if you break it down, you'll soon discover that the key activity has many different features tied to that specific activity.
- Charge a person a consistent amount using Paypal
- Charge a person a consistent amount using Stripe
- Charge a person a consistent amount using a different payment gateway
- Allow the site configurator to determine the period of time between payments
- Allow the site configurator to determine if the charges will be pro-rated
- Allow a person to change their plan, and have their charges pro-rated
- Allow the site configurator to determine if a person can pause their subscription
- Allow a person to pause their subscription
And that doesn't begin to highlight the little details related to the math involved in changing subscriptions when the rates change or the periods change.
See, I'm not saying the feature set should be small. I'm also not saying it needs to be large.
The reality is that it needs to be just right. But we determine what “right” means by determining the key activity that will help a customer feel satisfied and successful.
This is critical work. And it requires an additional focus on testing and quality.
The reality when it comes to prorating fees for subscriptions is that it's not simple work. And there are a variety of possibilities:
- A person changes from a monthly plan to a yearly plan
- A person changes from a yearly plan to a monthly plan
- A person changes plans that charge different amounts
Every one of these paths must be tested—rigorously. And it must be tested across a variety of payment gateways, in their case.
But this applies beyond subscription extensions. They're just my example. Because I know how much work goes into it. And I know the key activity and all the dependent features required to make that work.
Your situation may be different.
But it will still require that you learn to do one thing well.