Oh, Hello There

Nice to meet you!

This is my blog. I'll be writing about:

This was built using Glitch. Check out the project here.

Choose a post in the nav, or read the most recent one below. Enjoy!

Latest Post:

3 Big Product Development Risks

Building new things involves risk. If there is no risk in taking on something new, then there is likely little value to be gained. A great magic trick is to find low-risk, high reward work. It's like betting a dollar and winning a new car.

With every risk there is a % chance that it will turn into a problem. There is also how big of an impact the problem will be to the project. Another neat magic trick is ignoring low proabalitiy and low impact risks. They usually aren't worth the time.

There are three risks to every single project that have a good chance of happening and are instant 100% failures if they occur. Presented as questions they are:

If the answer to any of these are No you need to stop working on the project right away. Seems obvious, but the sunk cost fallacy is a hell of a drug when you're in the middle of product discovery, or have built 75% of a feature.

How can we answer these three questions? It is easy to answer these questions in hindsight after we've shipped and no one is using our new feature. It is impossible to answer these in advance. The challenge then is tailoring your discovery and build processes to help answer these questions along the way.

Did we build the right thing?

The right thing is something that users will use and will generate value for the company. There is no way to tell if you've built the exactly right thing; there is a healthy amount of risk/uncertainty that we need to take on here.

We want to get closer to the "right thing" through the Discovery process. We can interact with readers, test prototypes, test subsets of functionality to determine if what we are going to build will be used and generate value.

Did we build it in the right way?

Building something in the right way means:

Building in the right way means we are flexible and extensible. We're building with the entire application in mind and minimizing technical debt.

Did we build it at the right time to captilize on an opportunity

Not all opportunities will be time based, but those that are better ship on time! If we build the right thing in the right way, but it launches 6 months later than it was needed it is waste. It is possible to ship too early as well.

We want Insta-Pot timing. Capitilizing on an opportunity just as it begins to gain traction. Then we can maximize the value we gain from the opportunity.

Even opportunities without a fixed deadline have an optimal shipping time. This could be because of market opportunities, but also in delaying future work. If Feature A takes longer than expected it will delay the release of Feature B and potentially lower the potential value of Feature B.