How do you build a bare minimum feature?
shavinpeiries.com
How do you build a bare minimum feature?
1–10 of 23 posts
Re: How do you build a bare minimum feature?
#2> Do you find it difficult to ship?
Not really. Every successful company I’ve ever been at has sold the product before building it.
Small companies do it directly with customers, large companies do it with focus groups or A/B testing.
You can also do it with ads, make a lead gen ad for your feature, call the people who enter their info and sell them.
The goal on any call is to close. Either you sell them on your feature or they sell you on a reason they don’t need your feature.
Re: How do you build a bare minimum feature?
#3My tactic for getting past this (at least as a solo founder) has been to:
1. Talk to customers enough that you know what they actually want to achieve, and how specific additional features in your product will get them there
2. Ship the absolute minimal possible deliverable feature (a log of which I keep here: https://twitter.com/RozenMD/status/1364881512500404224?s=20), and mercilessly remove unused functionality after a few months of zero use.
Re: How do you build a bare minimum feature?
#4> Do you find it difficult to ship? Not really. Every successful company I’ve ever been at has sold the product before building it. Small companies do it directly with customers, large companies do it with focus groups or A/B testing. You can also do it with ads, make a lead gen ad for your feature, call the people who enter their info and sell them. The goal on any call is to close. Either you sell them on your feat…
Hi, do you have a blog or some place where you write about these topics?
Re: How do you build a bare minimum feature?
#5Great post, Shavin! Thanks for mentioning Deploy Empathy :)
Re: How do you build a bare minimum feature?
#6>So far your instinct as product designer/manager/engineer might be to take what customers say they want at face value.
That would be the worst way to go about building anything. Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does.
The question then becomes how does someone who generally knows how to build the right things build the bare minimum feature, the original question and title of the post, given the constraints on time and resources cited in the first paragraphs.
One can do several things. For example, writing the description and code examples for a yet to be library and shop it around, see if it makes sense, then write the library.
That's what I did for example with this library: https://pypi.org/project/bmc after shopping it around here: https://github.com/minio/minio-py/issues/829#issuecomment-65...
I also do that for internal tools, libraries, SDKs. I'll send client code around and see if it makes sense to engineers. I also had non engineers who never coded use libraries to do something useful. I just give them a laptop and docs and see how they use the thing. If they can do it, I know programmers can.
To get back to the original problem, prioritizing can lead towards minimal features. We have a section called "Instances" in our issue templates. If a feature issue does not have several instances where the problem manifested for several people, we just won't do it. We need concrete examples of a problem being frequent and expensive / high impact (loss of work, or prevents work in the first place).
For example, I'll look at the analytics for our internal platform and see that my colleague who we built the thing for is not using it. Why, we ask. It turns out the Docker images are too large and take a lot of time. He loses patience. They contain several libraries that he does need.
We built a minimal image that can get him to start after 30 seconds instead of 2 minutes, and we saw usage increase.
Yesterday, I saw he was giving a demo using his local environement, not the product. I'll ask why. What's wrong. What sucks. Why did he use his laptop instead of the platform.
The general sentiment of the article is sound. Always observe, ask questions, look for the underlying problems and how frequently they happen, how expensive they are (as in what are they doing to solve that, is there someone working on it, does it cost opportunities, etc)
Re: How do you build a bare minimum feature?
#7My tactic for getting past this (at least as a solo founder) has been to: 1. Talk to customers enough that you know what they actually want to achieve, and how specific additional features in your product will get them there 2. Ship the absolute minimal possible deliverable feature (a log of which I keep here: https://twitter.com/RozenMD/status/1364881512500404224?s=20 ), and mercilessly remove unused functionality a…
I'm curious how you handle close to unused functionality?
I find this problem acute in B2B software where only one customer adopts the feature, but it happens to be a very important one.
Re: How do you build a bare minimum feature?
#8> So far your instinct as product designer/manager/engineer might be to take what customers say they want at face value. That would be the worst way to go about building anything. Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does. The question then becomes how does someone who generally knows…
> * Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does.*
What’s amazing to me is how this concept is either a “you get it or you don’t” thing.
Sure, it takes a little practice to learn how to turn feature requests into the underlying business problem, but, like, I work with so many people who still can’t even grasp this basic concept after many, many years.
Re: How do you build a bare minimum feature?
#9> So far your instinct as product designer/manager/engineer might be to take what customers say they want at face value. That would be the worst way to go about building anything. Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does. The question then becomes how does someone who generally knows…
> * Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does.* What’s amazing to me is how this concept is either a “you get it or you don’t” thing. Sure, it takes a little practice to learn how to turn feature requests into the underlying business problem, but, like, I work with so many people who s…
This is dangerous as well, especially in enterprise deals where the prospects say they like the product but it lacks one feature, and someone on the team goes "Sure, we can add that" with the delusion that they'll close the deal if they just add this one feature. It rarely, if ever, is the case. If the "feature" is not about some specific security or compliance concerns but an actual feature, questions need to be asked during that meeting.
One common pattern is "Your product does not have X? Product Y has that feature", and one common pitfall for people who don't "get it", as you said, is "We should definitely add the feature X that Product Y has". One better approach is to ask "How long have you been using Product Y and how is it working out for you?". The answer is invariably "We don't use Product Y". Of course they're not; we probably wouldn't be meeting in the first place if they were.
Sometimes people tell me about products of my "competitors", or people from these companies make jabs or passive-aggressive snide remarks about me or the product: I'm building an MLOps platform; my competitors are people's laptops.
That pursuit of listening to prospects' features and solutions, or looking at what others are doing and following it is not a good way. Asking people what they are trying to do or accomplish and extracting problems is effective. What's the current state, what's the desired state, how they're trying to bridge the gap between the two, why they're failing to do so.
I wrote a bit about this here with the following example: a friend of mine asked me how to solder a thick wire to a thin metal plate. I asked him what he was trying to do. It turns out he wanted to solder a thick wire to a fuse because the fuse couldn't handle a stronger current and melted. I told him the fuse did its job precisely upstream, and gave its life so more important and expensive appliances downstream could live. This is one example of XY Problem: https://en.wikipedia.org/wiki/XY_problem
Re: How do you build a bare minimum feature?
#10Earlier quoted context omitted.
> * Taking solutions from customers as opposed to problems to identify jobs-to-be-done and reasons for non consumption isn't something someone who knows how to build products does.* What’s amazing to me is how this concept is either a “you get it or you don’t” thing. Sure, it takes a little practice to learn how to turn feature requests into the underlying business problem, but, like, I work with so many people who s…
This is dangerous as well, especially in enterprise deals where the prospects say they like the product but it lacks one feature, and someone on the team goes "Sure, we can add that" with the delusion that they'll close the deal if they just add this one feature. It rarely, if ever, is the case. If the "feature" is not about some specific security or compliance concerns but an actual feature, questions need to be ask…
Why would a company request a feature that wouldn't cause them to use a product?