👷 Product Builder Perspective

You, product


Main questions to ask when building a core experience:

  1. How do you get people through the front door? → Acquisition
  2. How to get them to an Aha! moment as quickly as possible? → Wow factor
  3. How do you deliver core product value as often as possible? → Engagement

Iterate to innovate

The fundamental criteria for innovation is learning is through frequent iterations.

💡 New value is a function of number of iterations.

The number of lessons you learn is directly related to the number of iterations you make, not the number of hours you put in.

As such, you should oriented your thinking and your processes to continually discover new value.

Optimize for amount of learning

Innovation is generated from a critical mass of learning. Each release should lead to one or more learning-generating outcomes (failure or success).

The goal of your processes and thinking is to get the cost of outcome generation down, and the rate of your learning up.

Any additional work beyond what was required to start learning is a waste, no matter how important it might seem at the time.

💡 Think of your work as a value-discovering experiment.

You should strive for frequent attempts in finding new value, enabled through a high shipping cadence.

Do the things that don't scale. Be inefficient. Maximize learning, not performance.

Some of your work won't make it past the internal development phase, some will get tried out in production but eventually get dropped, some will lead to improved KPIs (engagement, revenue, etc) and branch into more features.

No matter if something you've worked on is eventually included in the product or not, as long as you learned from it, it was a good use of time.

💡 Draw happiness from the amount of lessons you learn, not the amount of time you invest.

Validate against reality

Value can only be assessed against the real world. Your intuition can sometimes lead to short-cuts in value discovery, but often times it can deceive.

Until you measure the effects on real customers, you won't truly know if something is important or how effective it is.

Trying things out in production leads to the most valuable learning.

💡 Lessons drawn out of outcomes should be measured and validated through real world data.

Value = problem(s) solved + $ created

The outcome of your work is deemed to be successful when the end user's and your company's needs are reliably satisfied by the new solution.

Value provided to users maps down to anything that satisfies their internal need. Any work that you do boils down to a problem-solving effort. The more problems you solve for your customers, the more value you provide to them.

Value provided to your company is anything that directly or indirectly leads to its economic growth. This includes more users signing up, more users subscribing to newsletters, or more users buying offerings.

When arguing for or against a feature or implementation, evaluate it in terms of potential value it could provide. Always make a conscious effort to avoid bike-shedding.

People within an organization commonly or typically give disproportionate weight to trivial issues

Make sure to stringently eliminate the unnecessary. As Parkinson's law teaches us, the more time we have to complete a task, the more time we'll spend on it.

Mental Scripts

A perspective you should keep whenever you receive a vague spec or feature suggestion can be broken down in the following flow:

Prioritize by the highest potential value to the company bottom line. Any low-value tasks should be deprioritized.

Once a feature has been deployed, the general next steps you should take are:

If you cannot hypothesize if a change could provide a material outcome or a measurable improvement, then most probably it doesn't need need to happen.

© nem035RSS