Great post Ash. I love your “open box” approach by just laying everything out and telling your audience exactly how you do it. That’s awesome! One point I might improve upon is by defining an MVP as the minimum amount of work you need to do to get to a pivot. This is better than saying “to start learning about customers” because it doesn’t give entrepreneurs an excuse to take things slowly. By saying the goal of an MVP is to reach a pivot, founders acknowledge there is theoretically one or several “ideal MVPs” that will maximize learning and minimize effort. It also defines the maximum amount of learning possible as a that which is needed to reach a pivot.

Would love to chat further with you on these topics and others!

I guess the precursor question/comment is: 
* you start out with a vision of what you think is “feature-complete”
* you pick 5% of that to qualify as MVP to validate key assumption. You build, you launch, you start to collect data.
* You look at your data, decide which AARRR metric to focus on improving first. (It’s probably either Acquisition or Activation.)
* You start receiving customer requests, you do some interviewing.
* Then you have to pick from the customer requests plus that 95% of your own unbuilt features, which one to do first that you believe will have the greatest effect on the 1 metric you picked above.

And that becomes the input into the process above. Right?

And then the follow-up becomes, at one point do you conclude that you’re on a pointless-increment path and that it’s time to Pivot?

Generally, I do prefer to have requests from actual customers default to a higher priority than any speculative ideas we have. As long as it’s within the scope of the current vision, any time a customer expresses a particular pain, I try to let that override my own intuition of what their pain is. That’s kind of a fuzzy subject though and I think feature prioritization will always be mostly a guessing game (and thus the focus on qualitative/quantitative validation on the back end). 

My struggle is with including the validation as part of the overall process without ballooning overall work in progress to the point where it feels like we’re thrashing. I don’t know if I’m missing some key insight or if it’s just one of those things that you have to slowly improve as an organization.

I’m available for a chat anytime. 

One thing I’ve been a little weary of lately is the overuse of “pivot”. Not as a term but specifically as a cop-out over “perseverance”. 

Part of learning is dealing with things not working and identifying “why”. Sometimes you pivot but something you just fix stuff that doesn’t work aka bugs. 

Great points Wes… Lots of questions that could make mini-posts.

On added latency, I’d say it’s a question of going back to defining what real progress means to you. Is it pushing bits to fulfill your vision or building something people want? If it’s that latter, then you need to seek out both qualitative and eventually quantitative validation before going too far down the rabbit hole. 

It’s always easy to get customers to take a call for a feature they requested but the key to getting qualitative feedback beyond them is building relationships early with your users/customers. This is where customer development shines. It lets you do this organically so that by the end of the process the early adopters who are using your system are almost as invested in your product as you are…

I would pass “internal features” through the same process described above i.e. articulate a real customer problem (justification) for the feature, put it in front of customers and see how they react. 

Yes, I do like to time-box my experiments but the time period is relative based on the number of users/feedback cycle, etc. Same on quantitative validation state. When you first launch, you typically don’t have a lot of users so features end up staying longer in this state. Hopefully, that improves over time. The key, however, to tracking the impacts of features over time is using cohorts. 

The decision to pivot is a hard one and not one to be taken lightly. As I mentioned to Trevor Owen’s comment below, I find too many founders using pivot as a cop-out over “trying harder”. 

Eric Ries has a section on this in his upcoming book (The Lean Startup) that describes a process for running “Pivot or Persevere” meetings. You need to make an informed versus emotional decision. 

I’ve got a lot to say on freemium but I’ll start with making the distinction of freemium being more of a marketing tactic vs a business model. A perfect freemium system should work like a free trial (i.e. get users to grow into customers) with the added psychological advantage of “free” (which is huge). 

With that, I’d recommend that you only listen to customers and not users. Only once you understand how customers really use your system, are you in a position to correctly architect/balance the free plan to provide just-enough benefit for your users. 

As to removing features, it depends on how it’s done. I typically don’t do a marketing announcement until the feature proves itself to be useful. Partial rollouts, customer interviews, etc. all help to lower the risk along the way. 

But in the case where a feature gets rolled out to everyone and still doesn’t move the needle, I wouldn’t hesitate removing it provided you publicize your reasons. Most customers appreciate less clutter and simpler software and you’d be surprised how supportive they can be for fixing mistakes.  

If you follow customer pull i.e. if the feature was requested by one or more customers, start there. That’s the easiest way to get a motivated user on the phone because it was their idea. Frame the conversation around learning to understand their root problem, then ask them if you could show them the mockup/push the feature to them when it’s ready to make sure it solves the problem.  

Otherwise, yes it’s important to segment your customers. I have a list of  “power-users”/early adopters that I ping whenever we want to start building a new feature. I start by describing the problem and see if it resonates, then follow the rest of process. 

Yes in both cases. The first is easier. If while we building the feature we deem it “not worth building” for a number of possible reasons, we stop and explain our reasons why. 

We did this recently with when we removed some early work on “interviews tracking” in Lean Canvas. We realized that this was too big a problem to tackle for a small sliver of a startup’s lifecycle. There were also some good enough “cobbled up” alternative solutions we ourselves were using. So we informed our user base we weren’t building this feature anymore, explained our reasons why, and gave them possible alternative solutions they could use instead. 

I  use a 80/20 general rule where 80% is for improving existing features (which may be bug-fixes but also usability, flow improvements, etc.) and 20% is for new features.

I’d love to see an expanded version of the “Features vs Bugs” section. I’m a developer and it’s too easy to get caught up in the weeds of the code and miss what should be considered a “feature”.

Another Great post   with  Product life cycle charts ….

Would like to know more about how you tie github and kanban together