6 ms·

How do you build a bare minimum feature?

56 points by shavin47 5y ago

_3u10 5y ago
> 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.
- Jugurtha 5y ago
  Hi, do you have a blog or some place where you write about these topics?
  - _3u10 5y ago
    Just here, no blog.
- shavin47 5y ago
  This leads to building a feature factory. It's a more sales driven development approach. You'll eventually hit a scaling problem making it too concrete for some people or worse when there's a misfit between what the customers abstract representation of the feature request is vs. what you actually develop. Which then leads to more costly changes.
rozenmd 5y ago
My 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 https://twitter.com/RozenMD/status/1364881512500404224?s=20), and mercilessly remove unused functionality after a few months of zero use.
- wohlgejm 5y ago
  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.
  - mehphp 5y ago
    Personally, I feature flag them and hide it for all other customers. If the feature requires extra cost to keep going then I let the customer know the situation and charge them to keep it going.
- latchkey 5y ago
  Another 'tool' I've used in the past: We had customers that wanted 'permissions' for their "sub" accounts so they could have fine grained access to features. They would threaten to not use our system until this was implemented. Implementing this feature was a lower priority and more difficult to implement for us then other revenue generating features (also a good way to prioritize things). The interesting bit is they still used our system, despite the missing feature. I think because we focused on things that generated revenue. We kept good conversations with our customers and let them know when we thought we would add it. We kept delaying it and it took us 6+ months. In the meantime, we increased our (and their) revenues the whole time. Once we finally rolled out the feature, existing users didn't really care and new customers just had the feature. This strategy worked really well a number of times.
  - tata71 5y ago
    How do you avoid promising or implying shit you don't intend to deliver? I'm going through this right now — people trying to use super-fine permissions (dozens of points!). Besides role-based groupings, there's no chance this fixes more issues than it causes in my case (less technical managers and workers using an SaaS). Any ideas and insight appreciated!
    - shavin47 5y ago
mjwhansen 5y ago
Great post, Shavin! Thanks for mentioning Deploy Empathy :)
Jugurtha 5y ago
>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 https://pypi.org/project/bmc after shopping it around here: https://github.com/minio/minio-py/issues/829#issuecomment-658703470 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)
- JoeAltmaier 5y ago
  I tell this anecdote: ask a farmer from 1900, what he wanted, he'd say "A horse that pulls more weight and eats less oats!" He'd never have said "I need a tractor"

56 points by shavin47 5y ago

> 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.

Jugurtha 5y ago
Hi, do you have a blog or some place where you write about these topics?
- _3u10 5y ago
  Just here, no blog.
shavin47 5y ago
This leads to building a feature factory. It's a more sales driven development approach. You'll eventually hit a scaling problem making it too concrete for some people or worse when there's a misfit between what the customers abstract representation of the feature request is vs. what you actually develop. Which then leads to more costly changes.

rozenmd 5y ago

My 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 https://twitter.com/RozenMD/status/1364881512500404224?s=20), and mercilessly remove unused functionality after a few months of zero use.

wohlgejm 5y ago
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.
- mehphp 5y ago
  Personally, I feature flag them and hide it for all other customers. If the feature requires extra cost to keep going then I let the customer know the situation and charge them to keep it going.
latchkey 5y ago
Another 'tool' I've used in the past: We had customers that wanted 'permissions' for their "sub" accounts so they could have fine grained access to features. They would threaten to not use our system until this was implemented. Implementing this feature was a lower priority and more difficult to implement for us then other revenue generating features (also a good way to prioritize things). The interesting bit is they still used our system, despite the missing feature. I think because we focused on things that generated revenue. We kept good conversations with our customers and let them know when we thought we would add it. We kept delaying it and it took us 6+ months. In the meantime, we increased our (and their) revenues the whole time. Once we finally rolled out the feature, existing users didn't really care and new customers just had the feature. This strategy worked really well a number of times.
- tata71 5y ago
  How do you avoid promising or implying shit you don't intend to deliver? I'm going through this right now — people trying to use super-fine permissions (dozens of points!). Besides role-based groupings, there's no chance this fixes more issues than it causes in my case (less technical managers and workers using an SaaS). Any ideas and insight appreciated!
  - shavin47 5y ago

mjwhansen 5y ago

Great post, Shavin! Thanks for mentioning Deploy Empathy :)

Jugurtha 5y ago

>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 https://pypi.org/project/bmc after shopping it around here: https://github.com/minio/minio-py/issues/829#issuecomment-658703470 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)

JoeAltmaier 5y ago
I tell this anecdote: ask a farmer from 1900, what he wanted, he'd say "A horse that pulls more weight and eats less oats!" He'd never have said "I need a tractor"