Ask HN: How do you convince management to test before building a feature?

Don't assume the management hasn't done their homework, fair to ask questions but be careful not to sound accusatory saying why not do X instead of Y.

Not knowing if you work at a startup or a larger company it is hard to judge part of this. But if you are at a startup with a mature product there are valid reasons to not do an MVP feature release. The Lean Startup philosophy isn't right for everything, but it is a good start for new businesses/products overall, just not all. For a mature product or a product in a regulated industry (finance, healthcare, aerospace etc) the rules change and the maturity of each new feature has to be different. For example, in healthcare, you can't go to the FDA with a product and expect to keep iterating on features quickly, the product must be complete before submittal, and each new feature must be reviewed to see if a whole new submission is required or if an abbreviated submission can be used. Either way it is another cycle which takes months at best.

At this point, the management may have done enough research or market testing to justify the development time. Or alternatively they are taking a calculated bet and are pushing the product a specific direction intentionally. The larger the organization the less likely they are going to do an MVP because releasing small features and incrementing on it can be harder to sell to clients when you have a mature product and the clients have specific expectations.

Also, sometimes you have to build out a set of functionality that takes longer before a client can see it. Doesn't mean you won't necessarily have lots of smaller incremental milestones internally, but for feature release it might take 9 months. The more you make it into regulated work too, like aerospace, financial, healthcare etc the more likely this is to happen. Even during the development time, they may be presenting early demonstrations to clients just not releasing the feature for usage.

I think a large part of this depends on how long you've been with the company and what the team dynamics currently are. If you're new, this may be seen as you trying to "make your mark" and the management may feel challenged. If you're an established, trusted member of the team, then present a data driven cost/benefit analysis that will support your case. Present it in their language - management may be persuaded that an MVP carries lower risk and the potential for quicker reward.

As a VP, my advice would be to start off by understanding the management team. What drives them? Numbers, aspiration, risk, other factors?

Assuming the management team cares most about the finances and risk, outline what the costs and the risk factors of their approach vs the lean startup methodology. Present it to them as an option. But let them decide while positioning the lean startup as the less risky option.

I've always presented lean methodologies over long periods of development by highlighting the amount of engineering and project management resources it involves. Not to mention 6-9 months down the line, you might have wasted your time building something that your customers didn't want/need.

First of all, is this a place where there is significant uncertainty about the feature? Lean Startup-like approaches work best under conditions of uncertainty with unproven ideas. The easiest way to get someone's hackles up is to ignore work or testing that's already been done. Sometimes people have already validated an idea and the next chunk you can learn from is going to take some time.

Once I know that they've actually just been sitting around a table writing for an imaginary user, I have three options I've used: If the feature is clearly segment-able, I pitch it as delivering value sooner, rather than "testing". "We can build the whole feature in the same amount of time, but start making money in one month instead of 9" is a compelling proposal. And then once I've shipped part of it, I go back with the outcome of that and say, "based on what we've learned, we could improve the outcome by making these changes..." It is almost never the case that we make it through a 9 month project, because we've learned so much by then and we prioritized the most valuable parts up front, but I often don't say "MVP" at all. Frame it in terms of what it delivers to the business, not the users.

Second, which is useful if you don't have the power to actually structure product development, is the JAQing off approach: "How are we going to know if the project is a success? What are we measuring? That's an interesting design decision: how has that been received by customers?" The goal is to reveal the extreme uncertainty we are operating under and make the easiest solution the one where they adopt a learning mindset and iterative development. I had a CEO who used this to great effect: he never told people they had to build things iteratively, but he showed up to about one out of every four product reviews and if you wanted to be able to answer his questions most easily you just fell into that pattern. (His questions were always, "what are we trying to achieve?", "how will we measure if we succeeded?", "what evidence do we already have that this is worth investing in?" and "have you actually tried this with the intended user? What was the response?")

Alternatively, I just build user testing into the product development cycle/plan. You can have a 9 month project and still be learning along the way. Developers have to build some part first after all; it might as well be a part that you can learn from. Instead of getting management buy-in you get team buy-in, which is often easier because a series of small achievements feels good and iterative development is SWE orthodoxy. For this approach, I'd use user testing, internal customers or even just Monday demos of the current state of the feature to the team building it. If engineering already has a feature-flag framework it makes this much easier; if not, adopting the technical tools to make testing easier can also lead to more testing.