Product Coaching creates high performance Product teams that are the engine of innovative Product organizations that power successful technology companies

Product Coaching

It’s easier than ever to build technology products.

Today, the problem is figuring out what to build.

Jim coaches both beginning and advanced teams to use Product Discovery and Analytics techniques to find and test the next great idea (usually before ever writing a line of code).

As a Product Coach, he embeds within a team a few hours a week over a period of a couple months. This allows for the gradual and deep adoption of these new techniques.

He creates a custom plan for every team based on his curriculum derived from 25 years of making successful product companies, failing a few times and learning from top Product thinkers.

As the engagements progress, he coaches Product leadership on creating an empowered, innovative environment focused on teams solving problems by creating solutions that achieve success metrics.

Reach out to Jim Morris to coach your teams

To drive positive outcomes, a Product team’s effort must shift and expand

Adopting Product Discovery requires Product teams to think like business owners.

Too often, leaders push Product teams to hit deadlines and reward them for delivering on time whether or not their efforts drive positive business outcomes.

Usability → Value

Great usability is now expected of all Consumer and Business products. In today’s market, where competition is just a click away, Product teams need to create Products that customers want, love and come back to use again and again. We coach a relentless focus on Value. Once you find a concept that customers find valuable, then you can tune it with usability research.

Personas → Behavior

Product teams often create mythical customers in the form of Personas. They match a feature idea with a given Persona. But software products don’t solve a Persona, they solve a particular problem or create an opportunity. Often, the Behaviors that represent these problems and opportunities are shared among multiple Personas. By switching their focus to solving specific Behaviors, Product teams can shorten their time spent in Discovery and deliver Value faster. This shift to Behavior is exemplified by the Jobs to be Done movement.

Solutions → Problems

Everyone has an idea. And they can’t wait to share it. Too often, Product teams take an idea and run with it. But what problem does this idea solve? What opportunity does this idea address? No amount of marketing can convince today’s customers to adopt a solution that is not grounded in a painful problem or valuable opportunity. In the worst case scenario, Product teams have already built a “technology looking for a problem to solve.” Start with the Problem or Opportunity first.

Modern Product teams have data…Google Analytics, Adobe Analytics, Mixpanel, etc. They know the “what” and they analyze customer behavior without ever seeing or speaking with customers. Quantitative analysis can pinpoint problem areas or places of opportunities. But it can’t tell them “why” users are having a problem or what the driver of that opportunity is. Interacting with customers, showing them design prototypes, and gathering qualitative evidence are quick ways to validate ideas without using precious engineering time.

Quantitative → Qualitative

Learn to Conduct Successful Product Discovery Every Week

The Product Discovery Group coaches Product teams to learn Product Discovery in depth. Over time, these teams execute and apply Product Discovery themselves. All coaching sessions use the domain and subject matter of the specific team so that techniques are immediately relevant and all output is actionable. When we do user testing, all Product team members can and should lead user interviews. Combining a positive attitude with a few tips and tricks can help any individual work directly with users.

Byron, an engineer, quickly became a natural at user interviewing. Spending time at the client site also helped the team develop empathy for their customers.

Byron, an engineer, quickly became a natural at user interviewing. Spending time at the client site also helped the team develop empathy for their customers.

 

Inefficient. Stalled. Stuck.

Inexperienced teams go through the motions of Product Management

They deliver software via agile methods but are not agile themselves

They think more like project managers than business owners

“Products are delivered but fail to drive revenue, retention or any key performance indicators.”

“My teams eventually succeed but I see too much rework and misused engineering time. And their successes are not reliably repeated.”

“I give my teams autonomy but worry about lack of speed and focus.”

“I encourage my teams to work independently, but they don’t seem to have the skills to operate that way.”

“As I apply more control, results don’t improve.”

“My teams have freedom to innovate but seem detached from business priorities, customer needs or both.”

 

 Improve Your Product Discovery