Here’s an idea. A thought experiment.

Start with the premise that the best approach is to ship nothing.

I have a consultant friend who has a “minimum fee to leave San Francisco”. She will not leave San Francisco for less than $X,XXX per day. No exceptions. Since doing this, she has grown her business by leaps and bounds AND gets to spend more time with her family (win/win).

There’s so much focus on keeping teams busy that we tend to work on the “highest priority thing” without asking whether the highest priority thing is worthwhile. In this approach, priority is relative to the other things, not to some absolute guidelines or heuristic (similar to my friend’s per day minimum). If it looks better than the other things…well, we do it. Confirmation bias will lead us to say “of course it is important”…but is it?

The problem here is that added complexity is extremely costly. Development costs are only a small percentage of that cost. You also need to include increased support costs, sales and marketing costs, drag on future development, drag on onboarding, reduced extensibility, opportunity costs, etc. Consider the complexity to value exchanged ratio for some B2B products…it is scary how you often find the bulk of complexity delivering no real value to customers.

Imagine if we said … “we will not work on something unless it has the potential to increase MRR by $XXX,XXX per month of initiative time or more”. Note “MRR by X per month of initiative time” — this would let efforts of various durations potentially meet the criteria. If that number was $100,000, we could do a one-month effort expected to increase MRR (monthly recurring revenue) by $100,000, or a one day effort expected to increase MRR by $3,225.

Now let’s say you can’t figure that out. Well, that is a clue you need to learn more. Needing to learn is perfectly fine. The key point is that you have some sort of economic basis to your prioritization decision instead of just prioritizing ideas relative to other ideas. Often you’ll find that forecasting the value of opportunities is easier, and it is the solutions you’re struggling to predict/forecast. That’s fine…start applying leverage to the problem and measure your impact.

Ideally you have a track record of product decisions and some sense of what your big wins AND your modest wins look like. In real economic terms. If you can’t match those wins, then it is important to learn more.

What if the learning doesn’t require building? I’m sure there’s more than enough refactoring, small tweaks, and improvements the team can grapple with while that is happening. Plenty of “quick wins” can include reducing complexity instead of adding it.

Remember. The goal is to achieve the desired outcomes with the least amount of added complexity. Instead of focusing on keeping people busy…if you can’t really make a case for something, it might be a clue to step back and learn more.