Author: William Kammersell

Failing is vital. If your only plan is to succeed, you’ll never learn, and thus never have the crucial breakthroughs your product needs. Many enterprises only value success, so we fall into a pit of setting low goals to ensure success and hiding failures. In his excellent Mind the Product talk, Dave Martin goes more into why accepting failure is vital to a culture of innovation – https://www.mindtheproduct.com/2017/05/building-a-culture-of-innovation-through-product-management-dave-martin/

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
-Michelangelo

So, how do we set our teams up to fail, when they’ve been in cultures of success for years? For me, explicitly calling out expected failures and a little bit of story structure goes a long way. Here’s what I do:

• Tag or name user stories that may fail as experiments. This helps the team open their mind to being risky and think about the minimal amount of work to test an experiment.
• Create two additional stories for every experiment. One story is the additional support we’ll do if the experiment is a success, like hardening the code, adding more tests, and checking performance. The other story is what we’ll do if the experiment fails, such as reverting tests and code. Ultimately you’ll delete one of these stories and execute the other.
• Ideally, these two follow-up stories should have the same estimate. This shows that the appropriate amount of effort is being put into the experiment and you’re not over-investing in the success or failure route. An ideal experiment has a 50/50 chance of success to optimize learnings, so we want both routes to have the same cost. If you need to track the total cost for an experiment, take the more expensive path of success or failure (not the cost of all three stories).
• Once you’ve done your first story and measured your results, delete one of the stories, and play the other one, and share the learning from the experiment’s success or failure with others.

Hopefully you find this framework for tracking experiments helpful too. It helps the Team get in the mindset for failure, and creates the plan to fail so they’re ready to aim high and learn together.

This week at Mile High Agile I had the honor to lead an open space session about how Product Managers and Product Owners can work better together. It was a great session, with about 40 attendees, so I want to share what we discussed with you. Hopefully you’ll find it useful for either thinking about having both Product Managers and Product Owners or helping a new PM or PO explore how they can work with their peers. Or you may even want to use this format to run your own open space session.

I start my open space sessions by asking folks what they want to get from the session as they mill in. This greatly helps me set a flow and tone for the session. The first goal that folks had for this one was learning more about the alphabet soup of PMs, PMs, POs, and BAs. I took the first stab for the group, defining each and setting the framework with the venn diagram of usable/feasible/viable solutions. When I’m working with a PM or PO, I see the PO taking the central intersection of the three circles, while the Product Manager focuses on viability. The Product Manager does vital tasks such as market analysis, customer segmentation, and competitive research to discover customer problems that they are willing to pay money to solve. The Product Owner works with the Team to create the solutions that meet the customer problems that the Product Manager has identified. This framework resonated with a lot of the audience, and some other suggestions were to think of Product Managers as outwards facing and the Product Owner as inwards facing, or the two on a scale from Product Manager strategic thinking to Product Owner tactical thinking.

I then had folks who work as both PMs with POs to rate their experience with fist-to-five voting. Giving a 5 means you wouldn’t have it any other way, and a 1 means your experience has been horrendous. Most people were a 3 or 4 on their experiences, and I had folks go around to discuss why. The main theme by far is that it’s all about communication. Having great communication between the PM and PO is critical and gets a 5 while poor communication and understanding of responsibilities leads to a 3. Thus we shared ways to improve that communication:

• Take time to get to know each other. Get beers, go for walks, and lunch together.
• Share ideas, both the good and the bad. Share a lot so you both get in the practice of giving constructive criticism and improve each others’ ideas.
• Make a regularly scheduled time to talk. Save the space so you always have a venue to share ideas and feedback so that you don’t have to schedule a meeting when there’s an issue.
• Set roles and responsibilities. Be sure that you’ve got each others backs, but also are sharing effectively. You could talk through one of the frameworks above to make sure it works for both of you. You also consider using a RACI matrix to structure and document your agreement.
• Learn each others values and strengths. My favorite is to use StrengthsFinder to not only learn about yourself but also about your product partner. Many other personality assessments like Myers-Briggs, work great too.
• Make sure your development Team gets access to customer interactions and research from the Product Manager. Having a sense of purpose is essential to being motivated at work, and this can get lost without great communication. Hearing about the impact of a Team’s deliverables in the market is the most important of all.

Overall, folks liked having Product Managers & Product Owners to get two minds on the challenges of great product management and ownership. They can divide the many demands of product leadership to ensure amazing successes in knowing customer problems and creating solutions. The challenges come from poor communication, such as not sharing product results or leveraging technical innovations to guide customer research. Hopefully by using some of the tips we generated above you’ll be able to ensure your own success, and if you have questions or your own tips, please leave them in the comments!

Sprint demos can be tricky. So much gets done in a sprint, but you have to condense it down into a consumable package for a mixed audience of different roles. Or maybe not much gets done, but you or your Team have to demo anyways. Or you might find yourself demoing for a customer on a moment’s notice. Much can be said for the technical preparation and structure of the demos, yet I think there’s a simple ingredient that makes a good demo into a great one: passion.

Bringing passion to a demo means your excitement is infectious, getting your audience on the edge of their seats to see more. And being passionate should be easy; you’ve built your product and it’s your baby. It’s great to get to show it off! So what makes it tough to be excited?

• Our expectations can be too high, and we know all the times we had to say “no” while building, making it hard to see the awesomeness that remains.
• The Team’s velocity was poor, and only a sliver of what was committed got delivered. Again, we know what might have been and yearn for it.
• We have to build our product on the decisions of others, that we don’t agree with. It’s hard to get excited about showing product that’s hindered by others.

So what can we do to get past these blocks?

• Celebrate what is, not miss what might have been. If you made your stories well, there should still be value delivered, which no matter how small will still impact your customers.
• Personify your audience and think about demoing to someone who you know would be excited about your product, be it a key customer or peer. Demo as if it was just for them, and think about the smiles they’d have to see what you’ve built.
• Understand why former decisions were made, even if you don’t agree, so you can frame your work on the foundation you were given and feel great about the progress you’re making.

And if all else fails, hype yourself up with some motivational music before you demo!

Passion in a demo is so important, as it celebrate’s your Team’s successes, gets your stakeholders excited, and engages your audience. If you’re making a demo or giving feedback on another Product Manager’s, try to make yourself bored (like your audience may be when they come to your demo through no fault of your own) and ensure your passion comes through in your voice, words, and body language.

If you have any tips for bringing passion to a demo, I’d love to hear them in the comments!

Metaphors are an extremely potent tool for both communication as well as self-discovery. I’ve begun reading Your Brain at Work by David Rock, which gives the basis for an overall metaphor of how our brains work. Rock proposes we use the metaphor of a stage, with ideas coming, going, and vying for attention while we navigate our day. So far he’s doing a nice job relating several complex topics in cognitive science back to this metaphor to help readers heighten their understanding of themselves, and thus succeed.

In the first “Act” of the book, most of Rock’s tips have been codifying and justifying practices I’ve already done, like taking a walk over lunch to clear my head, but it’s helped me think differently about why these practices work (plus help me convince others to join me.) Going back to the metaphor of a stage, taking a walk basically gives actors a time to rest and your subconscious can have a breakthrough as other actors are allowed to mingle on the stage. There have also been several new tips and tricks that I can’t wait to explore:

• Treat prioritizing my day as one of the most energy-intensive activities. Do prioritization of todos early and avoid trying to reprioritize late in the day.
• Improve your mental braking system (not getting distracted) by practicing any braking, even physical braking.
• Think of your alertness level as an inverted U, where too little or too much alertness is an issue. Move your alertness level lower or higher through taking a break or visualizing a fear.

If you’re looking for a book to inspire you to think about your work approach differently, or help a Product Manager form their own best mental practices by laying a foundational metaphor, you should check it out. I’ll be making a couple more follow-up posts on the book as I read more of it so stay tuned for the final review.

One of my favorite email newsletters, Data Driven Daily, just posted its Archives! Data Driven Daily is a great way to get a little dose of statistics and data analysis each day with its extremely approachable and relevant topics of making better decisions through data.

Each week typically follows a theme, and some of my favorite series so far have been:

• Game Theory – A nice primer to get past this intimidating term and learn when and how to use it.
• Dirty Data – For those doing their first data analyses, a perfect reminder of what types of bad data to be on the lookout for.
• Funnels – One of my favorite data analysis tools and one that a new PM should know how to interpret.

Hopefully you find your own favorites in the Archives and it helps you or your new PM get more comfortable collecting, interpreting, and acting on data.

It’s mid-January, and New Year’s resolutions are starting to melt like snowmen. Reality begins to bite after the lovely winter time-off with the start of a new quarter. So what are we to do about losing our way? Recently a couple articles inspired me to get back on track by connecting one of a PM’s top skills, customer empathy, with setting and achieving personal goals.

First, The Atlantic published “Self-Control is Just Empathy With Your Future Self.” The article discusses the neuroscience between self-control and empathy for others. I found the analogy between our future selves and others to be fascinating as both are just as unknowable. If we treat our future like a potential customer, there’s a lot we can do to make sure we convert our future to a reality.

The New York Magazine also has a series “How People Change” with “To Change Your Life, Learn How to Trust Your Future Self.” This goes a step further by saying that not only do we have to listen and empathize with our future selves, we have to trust them. Make decisions that may have short term pain for increased gain for our future selves.

So, how can we take advantage of this connection between empathy for others and ourselves? We can leverage the tools we use to gain customer empathy, like an Empathy Map, and use them on a projection of our future selves. Make a vision for what you want the future to look like, and how you’ll feel when you realize those goals, to inspire yourself to make hard decisions today.

Another way is to build on the popular mantra of setting just three goals each day, and make them serve your future selves. For instance, each day you could:

1. Do something that will help you tomorrow
2. Do something that will help you next week
3. Do something that will help you next month

Of course, you can tweak the horizon for each item to fit your goals, even going out to a year. The advantage is to make a simple way to set goals to incrementally progress to your future self. By thinking concretely about what you want your future self to feel for each time horizon, you can more easily make concrete steps to get there.

If you’re training a new Product Manager, you can help them set their first personal goals by creating empathy for the Product Manager they want to be, and then deconstructing that vision into actions that help them get there one day, week, and month at a time. Hopefully you also get inspired to set your own goals, or get your New Year’s resolutions back on track!

If you’re getting writer’s block while drafting your New Year’s resolution, try flipping the problem and focus on failure over success. When we set our annual goals, we’ve been trained to look for success, and when that success doesn’t come we often just leave our goals behind. Defining success can be very hard even if you know tricks like SMART criteria, as shown by all the broken resolutions in February. So instead, make your goal to fail. If you’re not failing, you’re not trying hard enough, so resolve to try your hardest and fail gloriously. Be like Times Square, and ‘Drop the Ball’ this year!

Picture the fear of failure that’s holding you back. Is it looking like a fool? Losing money on an investment? Finding out you don’t have the skills you thought? Then set a resolution to make your fear a reality. Make yourself a fool in front of a large audience. Take a risky bet. Try something totally new or return to a skill that’s rusty. If you succeed, you learn a lot about yourself along with new skills. Or, you fail to fail and end up with a win, and another broken resolution to add to your list of incomplete ‘success resolutions’ from prior years.

If you’re helping a new Product Manager set their own goals, creating goals to fail makes a safe space for learning, personal growth, and expanding boldly into their new multi-faceted role. Even if the final goal is written as a success, thinking about failure can jumpstart creative juices and lead to key steps to achieving success.

Good luck setting your resolution this year. Failure awaits!