Helpful constraints for product development

The information below is learned from releasing 20 something products as agency and now a product company. I understand that you may have a different experience. This is just one set of constraints that in this particular combination have been found to work well. There are many ways of doing things.

When we want to build a new product, we usually think of a “promise” we want to make the user.

This is usually something that we believe wows them if done right.

This promise is usually dependent on multiple experiments working out favorably. That doesn’t happen most of the time.

Experiments are done on parts of the product that are highly variable.

What also hurts us is that products that depends on multiple experiments have the likelihood of being too complex to imagine in terms of single user experience. As a result, we tend to forget things. We get lots of blindspots.

So even if the experiments end up working out, we forget something else that’s critical to the success of the project. Could be on pricing, ux, marketing, a detail of a particular feature it, a large competitor… you name it.

It’s just too much and we’re too limited as humans.

Here are some helpful constraints that help you avoid at least some of the avoidable cases

  • Hammer out highly experimental features before your product release definition. One of the biggest mistakes. We tend to mostly define the product story with an assumption of how those experiments work. Those assumptions usually get revisited way too late.
  • Don’t start the project before these highly experimental features / tests are done.
  • Only run one experiment at a time. You discover anatomy and limits when you run experiments. These ideas will shape how you think about other experiments. Start with the experiment that can invalidate other experiments to save time.
  • Be ready to re-define the product definition and your “promise” to your users when you finish your experiments. After each experiment, question the promise you were going to make to the user. Can you still keep it?
  • Don’t have any releases be more than 3 months. This will keep your complexity low.
  • Get as much as market data as you can. Be forced to show with data as to why something is a good decision. It’ll force you to not make silly mistakes that others have made. People say “this has never been done before”. Maybe not that exact thing but there are clues everywhere. Go look for them. You don’t need perfect data.
  • Have clear incremental milestones that lead clearly to your product at least one every 3 weeks. This will also force you to discover issues earlier and force you to build in a modular and incremental manner.
  • Don’t involve your whole team in the product definition. There is only so much data out there to support certain decisions. Do your best to get the data to show that direction but in the absence of that, someone in the team needs to own all the grey spots. All those grey spots need to have continuity in thinking and constantly be questioned by that person. That’s impossible when that responsibility is spread across multiple team members.

I leave with you with this nice quote

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” — John Gall