Stakeholders Should Explain Problems, Not Ask For Features

The main goal of a software product is to solve a problem (or multiple), not to have features.

Pen in space with Earth behind (generated by AI—in case it wasn’t obvious 😅)

Myth

A myth at NASA illustrates why stakeholders should communicate problems instead of asking for features. I like to imagine that it went the following way:

—We need to send the astronauts to space next year—says some upper manager of NASA—do we have everything ready and planned?

—Yes, sir, the rocket is on schedule, suits as well, equipment on track. And everything is ready for the experiments—says another upper manager handling the teams.

—How will they record and report the experiments?

—We created some templates (paper templates; this was the 60s so computers were not so commonplace) so they don’t lose time with boilerplate,—replies—they will fill them up.

—How?

—With pens, sir.

—But pens don’t work in space!—at this moment, the upper manager feels he deserves the salary he gets.

—Oh!—realizes, ashamed—oh no!

—We need pens that work in space!

—I’ll set up a team to work on it, sir.

A team was assembled to solve the problem and build a pen that works in space. They spent one million dollars, but finally, the pen was ready when the astronauts went into space.

Meanwhile, the Russians went to space with a pencil.

Features from Upper Management

The myth did not happen in reality, but we all had similar experiences. Upper management requested a feature that seemed valid, only to realize afterward that it was a waste of time.

UX researchers and product managers know we must gather needs, not just features. The main goal of a software product is to solve a problem (or multiple), not to have features.

Therefore, apply the same mindset when upper management requests features. Treat them as users and ask them questions to find out the need behind the feature.

Global Vision: Needs vs Features

A significant risk of working on features instead of needs is to end up in “local maxima.” A local maxima is the highest point in a subset, but not necessarily in all the set.

If we work on features, we are limited; we do incremental changes, always going up a hill, but we don’t know whether that hill is the highest.

There is nothing wrong with incremental features; it’s the most common way and adds value. But it has the hidden risk of local maxima. That’s why we should never lose sight of the users’ needs.

The users’ needs are the global vision that helps us find the global maxima.

Next time a manager asks for a feature, ask further questions to find the need instead of following the request blindly: keep a product engineer mindset.

Thanks to Yusef for reviewing this article!