Tell me if you’ve heard this one before, you have signed up to deliver the improbable, your project is tracking better than you expected and against improbably odds you might even pull it off – if only you can figure out what to do next. This is a blog post about stories and the noesis that results from stories applied to daily challenges. 

If you have heard a lot of about stories recently, you can thank Dan and Chip Heath. Their accessible books, Made to Stick and Switch, combined research and written accounts to demystify how certain concepts take root where others are forgotten. The storytelling concepts are simple, easy to follow and can be applied to simple business problems; though I recommend both books the concept of applying stories to problem solving is not new. 
The Case Method 
Harvard Business Review’s Ben & Jerry’s case opens: 

“As Chuck Lacy composed his thoughts before the September 1990 Ben & Jerry’s board meeting, he knew that the central decision of the day would set the tone of the company for years to come” 

Like other HBR case studies, the Ben & Jerry case tells the story of a fractious business situation. At the world’s most renown business school, to be Harvard educated is to learn through narratives. 
Turning the Pen Inward 
The same methodology used to lasso complex business issues can be used to wrangle your own life. The power of story is the ability to articulate in organized thought the issues at hand as well as surrounding context. If we can apply our best thinking and identify coherent solutions to external issues by placing ourselves in the protagonist’s shoes, what happens when the protagonist is you? 

When I face tough projects, I like to write myself out of the problem. I begin with a safe and familiar opening, just to get my brain going: 

“The protagonist Mikal Lewis finds himself in a familiar situation…” 

Next, I begin in free form to articulate the issues at hand: 

“Management has approved his request, sanctioning his project, and with it come the expectations of success” 

I then develop the surrounding context: 

“The problem is with three weeks before the conference, Mikal has to find a way to reach shared understanding of the issue at hand, and recruit project team members, without setting off a political hailstorm” 

Two quick notes, this is not based on a real situation and Mikal does not I do not typically refer to myself in the third person; but you get the point. Write out the background context, be sure to document the facts, it’s best to keep how you ‘feel’ off of the page, it clouds the action driven narrative. Pay close attention to background context and intertwined conflicts that exist but are convenient to overlook. When writing be very candid about your strengths and weaknesses. 

Congratulations, you now have your own case study for your unique situation. Now turn it into a story, and write the next chapter; how does the protagonist get him or herself out of this complex situation? How do other characters react to the main character’s actions; what alliances does the protagonist form? What is in it for the other characters in your story? 

You are well on your way to writing yourself out of this situation. 

No deus ex machina.

As Greek philosopher opined, “you can never step into the same river twice.” This post is an ode to time—the true source from which learning derives.

As a product manager, a significant portion of my role is fostering decisions. This comes in many forms but my personal maxim is to minimize the number of decision’s I make at any point in time.

Minimize the number of decisions made at any one point in time.

It’s important to visit the assumptions that would drive a maxim such as this, so here are mine:

1. The right answer reveals itself with time
2. Distributed decisions win in the long run
3. We will be smarter tomorrow than we are today

Independently, these are easy maxims to nod your head to. In practice, it’s incredibly difficult to organize a team and keep a team organized around these principles.

In a product organization, you’re seemingly forced to make decisions every day so it’s important to reflect on how I’ve turned this into action.

1. Develop empathy for the problem space. Really understand it, listen to the domain as if it’s a full body experience. What assumptions does the industry have to believe for the industry to be where it is? Where is it wrong?
2. Don’t pay above market value for knowledge. Should you ship a chainsaw without a safety throttle? No. Some knowledge is already in the world. Don’t ship a product to learn a lesson that’s available in a $30 book or a $10 research paper. But there are two issues with relying on empirical knowledge, the first is a tendency to treat all empirical data as knowledge. When much of it is information, or worse anti-knowledge—information confused for knowledge that actually makes it harder to achieve knowledge. The second is a priori knowledge is the most powerful skill you can harness, can you grow a multi-billion dollar paintball business with one location? Is the probability of this business more or less probable than Bigfoot? Examining ideas through inquiry is a powerful way to improve your first idea over time.
3. Go with your first idea. When all information is equal and in absence of validation, your first idea is just as valid as all others, go with it. Save the time debating whether or not it’s the best idea (because it isn’t) and spend it increasing the probability of success and time to market of the first idea. This will free you up for your next first idea. This is effectively a greedy heuristic for decision making. Over time: a good enough decision fast bests a better decision slow.
4. Reduce the cost of change. On a software project, we tend to think about the cost of change in terms of how much code needs to be thrown away, but cost also includes entering partnerships that are difficult to get into and hard to get out of, services that are quick to stand up but are difficult to throw away. Finally, change is often hardest for people. Ship the idea that is easiest to walk back socially, which often means ship the idea that is the least right politically. There are some ideas that can’t be walked back politically–as in if it fails no one will have the heart to walk it back. Ship those last.
5. Optimize for adaptability, not predictability. As a product development org you want a highly adaptable team in most parts of your system. Since you don’t know where your perspective will take you–it’s important that everyone understands the conscious trade-off between an adaptable system and a predictable one.
6. Try to live with your product for as long as possible. Do this by shipping it as early as possible, not by shipping it later so you can use it longer. Does it become something that you can’t live without? Do you become disinterested with the product over time?

Note: Last year I wrote on a related topic: Your Codebase is The Best Prototype

In practice the software project unfolds like a sketch artist, making hundreds of noncommittal strokes to the page. No one stroke is “right” but taken together, a clear form begins to emerge.

While there are artists who can create this in one go, with bold lines drawn at the outset, I’m not one of them and probabilities are that you aren’t either.

While looking at this you could easily focus in on the small deliberate strokes, but what’s more important is the time between each stroke. With each stroke you gain new information, feedback about how the bigger picture is unfolding even if others can’t see it yet. If you blindly placed each individual stroke without regard to how the others that proceeded it turned out you’d have a very different picture.

While we’re all familiar with the principal that knowledge is in the world, it’s important to reflect further on how much of that knowledge is only possible through the dimension of time.

Time is information.

Reflections

Time is information. Much of our job comes from identifying waves that are high growth. Growth, like acceleration, requires a function of time.

Time is information. The current project state tells you one thing, the same project state for a year tells you another.

Time is information. If you live with an idea for a day and are excited and live with it for a year and are still excited.

Time is information. How you use something changes materially with time, strong behaviors become stronger weak behaviors are replaced.

Time is information. You have 200K customers. Hooray! 30 days ago you had 1M customers. Oof.

When doing think. When thinking do.

A career swings between two extremes, leveraging strengths and mitigating weaknesses. A tactic I’ve found helpful through each swing of the pendulum is immersion—an approach for building on strengths and mitigating weaknesses.

You might adopt this tactic in the midst of or leading up to a moment that requires uplevelled skills in any one area. When leverage your managing and leveraging your own curriculum.

What to focus on?

The first question at any time is what to focus on. The key principle of immersion is that you choose one area of focus at a time: visual design, typography, team communication.
The right area to focus on will come to you swiftly with just a moment of reflection:
What is the single most important area for me to improve to get where I’m going.

This question is temporal. Your goal is to constantly improve the single most important area—similar to chain runs. You’re constantly improving the most important area, until there is another most important area.

Time box it

Take to your journal and write a concrete goal. By X, I will be better at Y, as demonstrated by Z.
Your time horizon should be a 2-8 week interval.

Build a list

What about all those areas you didn’t focus on? well build a list. I use a simple excel file to prioritize all my potential areas of focus and come back to it.

Reading list

Ok, now plow Amazon, or your favorite library and put your money where your mouth is. Acquire 2-5 books on the subject area.
You’re going to read them in tandem. One book is your primary read, and the other is your change of pace read. So for example listen to an audio book in the morning, and read a different book in the evening. The goal is not to plow throw books in the domain, but to replicate a good class environment. You’re hearing the same ideas from different perspectives—forcing you to synthesize versus rote learning.

Activities

With your reading list at hand build a set of activities you will do to exercise your idea.
This is critical because you need both “know what” and “know how.” Riding a bike is “know how”—teaching your child how to ride a bike is “know what”.
Let’s combine theory and practice.

Do it all again

Times up it’s 8 weeks later. You’re improved at this. Take a break, or dive into your next immersion.
I’ve used this approach to:
1. Learn visual design
2. Learn tableau
3. Learn illustrator
4. Learn regression analysis
5. Learn presentation design
6. Build forecasting models
7. Learn the foundations of philosophy
8. And countless others…

This calendar year has been one of progress. In addition to launching Your Look at Nordstrom.com, I have the fun challenge of the front lines of retail disruption through leading a redesign of the Nordstrom Product Page across desktop, mobile web, and app.

My product philosophy is nuanced and difficult to summarize. Correspondingly, the same elements that make my product philosophy apophatic are the same that make it successful. My product philosophy is divergent. That is, my philosophy diverges from the expected.

Growing up hip-hop

The smoothest bridge to my perspectives on product development and strategies is hip-hop. As an up and coming emcee, I learned the process born out of taking something known, let’s say a record or an aphorism, and transforming it into something completely new and different.

Read the full post on Medium.com

For those learning the Product Management discipline, Inspired is one of the best books you can start with. However, don’t take the book literally, Marty Cagan offers some extremely hazardous guidance in advocating for high-fidelity prototypes as the only means of shipping software: