How to Know When a Product Offers You Negative Value

GrumpyI just tried to join a virtual conference in a new-to-me distributed meeting product. It's supposed to be “easy” and “smooth.” Not for me. I stumbled around for 15 minutes and then left, totally unsuccessful.

All the participants are supposed to have avatars—but I never understood how to set mine. (I do have a Gravatar. I'm not sure why that was not the default.)

The tool is supposed to take our camera and mic settings from the browser. I tried, but while the camera worked, my audio did not. Geographically distributed teams don't need cameras for full participation, although I prefer them. But no one can participate without full duplex audio.

I'm supposed to be able to move rooms/locations inside the tool, but when I tried, I got kicked out altogether. When I tried to find another room, I discovered a room that belonged to someone else entirely—someone not in the conference I was supposed to join. Now I'm worried about security.

Here's what did work: the artistic background for the virtual meeting space. That's it.

This product offers negative value. Instead of being neutral, I now know to avoid meetings with this product in the future.

While I have some patience with new products, this one has insufficient robustness. That's a function of bad/insufficient requirements and unfinished implementation. (I suspect the developers also didn't test enough, but I can't tell.) And I bet the developers never used this tool for their collaboration.

But from a product strategy perspective, there are already existing robust products that offer much more functionality.

Don't recreate the wheel. You have other choices so you don't have grumpy users like me.

How You Can Prevent Developing Products With Negative Value

I like to start with why we are developing the product. That means I start with the product strategy:

  • What unique problems do you want to solve for your ideal users? (No product has this functionality or has it at your expected price point.)

Then, review your tactical boundaries. See the Project Pyramid and the Innovation/Determinism continuum in How Product Risks Differ from Project Risks:

  • Do we know what matters most to our ideal users? (If you're competing with an already-existing product, the more robust your product needs to be.)
  • Do our current people have the skills and capabilities we need to solve those problems?
  • Do we have enough time or money to develop and test our work? (Do we need capital expenses, such as a lab, or operational expenses, such as more people?)

I don't know of an organization that can plan their way out of these risks. However, you can define the product strategy, and then use short feedback loops to clarify all the tactical boundaries. You don't need to spend a lot of time on those tactical bounds.

And what about the artistry that's involved in the product?

When I first entered the conference, I thought, “Oh, this product looks good. I bet it will work.” But it took my less than five minutes to wonder why this company had chosen to spend time and money on artistry instead of spending time and money on functionality and security.

Every product is different, so you might make different decisions. But in my years of experience as a user and product developer, I prefer to see robust functionality over artistry that does not help the product experience.

Don't create products that offer negative value. It's not worth your time or your users' time.

Leave a Reply

Scroll to Top