
Ask HN: How do you convince management to test before building a feature? - dmcbrayer
I believe that it&#x27;s almost always better to build  and release something basic and iterate on the feedback you get from your customers than to work on something for a longer time and only release it when it feels &quot;done&quot;.  My previous assumption has been that this is basic product development orthodoxy. In my case, I was heavily influenced by Eric Ries&#x27; Lean Startup book.<p>This week, I&#x27;ve learned that management has been planning a major new feature that would take 6-9 months to build, but don&#x27;t have any indication that they&#x27;ve tested the idea or want to do a minimum viable product.<p>I don&#x27;t see this as a problem just yet, more of an opportunity to initiate discussions about building MVPs. The strange problem I have (and perhaps I&#x27;ve had a charmed career so far), is that I&#x27;ve rarely had to actually make the case to a skeptic that the Lean Startup approach is better.<p>When talking to management, what have been the most convincing things you&#x27;ve shown them about why this is a good practice to follow?
======
davismwfl
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.

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

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

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

