Throughout my 12+ years of experience, I've been building software that addresses the problems of the User, plain and simple. However, the process for how we build software has changed drastically.

When we first have a product, let's call it a 0 to 1 product, there's little to no risk. Assume we paired in a small group, a designer, a "thinker," an engineer. This small group has all of the autonomy that they require to make rapid and informed decisions.

In a sense, not speaking about capitalization of a business, they're very well resourced. This small and nimble group can act quickly, adjust, measure, learn, and launch.

Throughout my career, I've had the pleasure of launching a number of small and large initiatives that has shaped the way that I look at internet businesses of all sizes.

METHODOLOGY

All of the product management tools at our disposal help to do one thing: make decisions. Peeling back the lens one layer, making decisions is about making good investments.

The book Working Backwards had a profound impact on me. Mostly, to support systems and tools that I always firmly believed in. A single EPD pod or delivery team can be quite costly on a business. And it should be of utmost importance to those managing the delivery team to ensure the profitability of the teams time and effort.

That age old interview question of "How do you prioritize features?" I love the question, however, I have mixed feeling about the outcome from the answers usually given.

In a startup business, your objective is to solve a problem as quickly as possible. However, it's important that problem is large enough to actually charge a fee for it. I learned rather quickly in my career that not all problems are those valuable to customers enough to give you money for it.

Sometimes, software can be "neat" and "cool." However, fail to really be something that solves a deep need. Specifically, one that solves a need better than others in a market.

In a scaled business, this methodology changes quite dramatically. Because you have an adopted and well-informed group of customers who know exactly what you do, why you do it, and what you solve for them.

Your job becomes about supporting that value, in every single way possible. And reducing your time-to-value. OKRs, KPIs, CSAT, NPS, all the abbreviations of "things" that we track, look at, analyze—are all simply obfuscations of groups of customers general census.

WHO, WHAT, WHY, WHERE, HOW

At the core of all of the latest process around product management. Like the Jira tickets, the backlog grooming, the agile reports, the thematic A/B tests, all of it—we're still getting down to the who, what, why, where, and how.

I've launched great products and features in companies large and small. Ranging from $0 in revenue to $1B in revenue. At it's core, we are always looking to do a few things, if we were to generalize:

1. Solve a customer need.
2. Reduce risk on the business.
3. Accelerate the customer experience.
4. Exchange value between customer and business.

By taking this simplified approach and utilizing all of the gregarious and wonderful tooling that exists in software development. I've been able to better connect with customers, lead teams, keep efficiency at a consistent pace, reduce time-to-value, and build software that's enjoyable and pleasing to use.

Ch. 01: BEGIN

Throughout my 12+ years of experience, I've been building software that addresses the problems of the User, plain and simple. However, the process for how we build software has changed drastically.

Ch. 05: END