It’s time to plan your next big product release. You sit down, set a goal for 12 months out, and get to it. What happens next is one of the common fates for traditional product releases:
Your changes go slowly, leading to missed opportunity and demotivation
Your funding runs out, and you have an undelivered, half-finished release
You have to make so many compromises to keep on budget that you ultimately miss the outcomes you desired
And that’s why agile methods are used today. Rather than setting a target for a year out, we iterate and experiment with our product ideas to create the outcomes we desire more effectively and efficiently. So why do we still adhere to traditional personal resolution setting? It ends in the same outcomes as traditional projects with broken resolutions or spent effort without the results we wanted. We either stop going to the gym and feel like personal failures, or keep going to the gym and don’t lose pounds. And if you do keep your resolution and get the massive results you crave? Then your story is so unique its bound for the front page of Reddit.
The failure in your resolution isn’t your fault, its in the way we all set resolutions to execute on our vision for a better self. So this year, break your resolution early, and start experimenting! Instead of setting a 365-day goal, use a iterative approach and set a 14 or 30 day goal. For instance, rather than committing to a year of getting up early to write blog posts, commit to sleeping from 9pm-5am in January to get up early to write your blog. At the end of the month, have a personal retrospective. Did that work and you saw the benefits? Great, do it again in February! Did it not work? Then pivot and sleep from 10pm-6am, or find some other time to write blog posts! Whether your experiment passes or fails, you’re not a failure, and you’re sure to learn a lot about yourself. And now you get 12, 24, or more opportunities to find your next breakthrough in personal happiness, performance, or whatever your vision for 2018 has in store. Resolve to experiment!
Did you know that wearing a hat can lead to truly understanding problems and comprehensive solutions? Wearing a hat changes your perspective and stimulates your mind. And the best part is, it doesn’t even have to be a physical hat! With Edward de Bono’s six thinking hats framework you can focus your mindset on different aspects of problem definition and solution creation in a matter of minutes. Let’s take a look a brief look at the six hats and how you can use them every day.
The six thinking hats are six states of mind that we all go through, each represented as a colored hat:
White – a factual mindset. White is clinical and pristine without being sullied by opinion. What are the facts for our problem or solution? What, if we knew it, would change our outlook? How could we get more data? What do the trends of the past tell us about today and the future?
Red – an emotional mindset. Red is the color of passion and emotion. This hat gives credence to our gut reactions as we trust what our mysterious subconscious is telling us. How do we feel about this problem or solution? How would or do others feel about it? Is there FUD?
Yellow – an optimistic mindset. Yellow is the sunshine giving a happy positive outlook. What are the upsides of the problem or solution? What does stunning success look like? What advantages and opportunities do we have? How can we take advantage of our strengths?
Black – a pessimistic mindset. Black is the night casting shadows on your decisions. This mindset lets you play the devil’s advocate to holistically consider all aspects of your problem or solution. What does failure look like? What are the risks? What will be the first roadblock? Why is this an impossible situation?
Green – a creative mindset. Green is the color of life and growth. No idea is too crazy. What are we not considering? What are ways to avoid the problem entirely? What is the second best solution to our problem?
Blue – a control mindset. Blue, like a police uniform, enforces process. Did we consider all our hats? What do see after exploring all our mindsets? What outcomes or actions will we take going forward?
At work, I gave a mini-workshop on this framework and it was exciting for all of us to engage with our hats as the framework’s language is very accessible to everyone. We all have our favorite hats, and as product leaders we often find ourselves wearing different hats depending on our group. If a Team is being data-driven with white hat thinking, we can bring emotional red hat thinking to give passion to a problem. Or too much yellow or black hat thinking deserves the complement to ensure we’re being realistic in our assessments. Practicing the six hats can ensure we have the skills when a hat is needed. For example, I personally lean towards blue and green hats, and struggle with red hat thinking.
In our workshop, we took one of our company problems and trusted the process by going through the hats in order. We started with blue to outline the process for our session, went through each hat for about 5 minutes each, and finally came back to blue to tie it all together with an outcome or next actions. Using a whiteboard divided into 2 rows of 3 columns, one cell for each hat starting with white, is a great way to collaboratively take notes and show the progress through the hats. The results were great and we were all stunned by where we got in a short amount of time. It’s certainly hard to focus on only one hat at a time, but we got there after some practice.
If you’d like to learn more about the six thinking hats, there are many summary articles that go more in depth, or there’s the full book Six Thinking Hats. With it being such an accessible model, it can be a great choice for a new product manager as well as they learn decision making through shuhari. By starting with a semi-prescriptive framework they can build the confidence to start experimenting with their own decision making patterns. For me, the best way to learn is by doing, so take some time on your next challenge or opportunity and purposely think with all your hats and see how your decision improves!
What’s your favorite hat? What hat needs improvement for you? We’d love to hear your stories in the comments.
Growth is a constant process. Everyday we strive to be our best, either succeeding or failing, but always learning. It’s important that we take the time to internalize those learnings lest we lose the day’s growth. And the simplest process, Think Time at the end of the day, can turn each day’s lessons into a habit for years.
Think Time is a daily ritual of spending 5-15 minutes at the end of each day reflecting on how the day went. Where did you win? Where did you fail? What can you learn? How can you take today’s lessons into tomorrow to continually grow? You can do it at the end of the workday, on your commute home, before bed, or whenever you’d like. Just try to make it a consistent time so you build a habit. I personally do it before leaving work, around 4:30, and use a set of questions to help me appreciate the day’s gifts and focus on where I want to improve. My current list:
Where did I fail today, and what did I learn from it?
Who did I appreciate today? If no one, who can I appreciate before I go home?
Who inspired me today?
What did I do today that scared me?
As an example of using these to enforce habits, the question “who inspired me today?” was added after I realized my natural reaction to others’ successes is to be jealous. To help break that reflex, I try to purposely frame that jealousy into inspiration at the day’s reflection.
Think Time is also a great way to help others in their career by coaching them on a set of questions they can ask themselves each day to create healthy habits, change mindsets, and always appreciate personal growth. Hopefully you have success with Think Time as well, and we’d love to know your favorite daily reflection questions or thought points in the comments.
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.
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.
You’ve done your user research, understand their problems, and now it’s time to communicate your insights to your team and stakeholders. You may be tempted to create a persona document, but there are majorflaws! The persona you create may be a Frankenstein of your actual customers. You may take a little of this and a little of that from each user interview and the end result is a user that doesn’t exist, leading to incorrect product decisions and wasted time. Instead, try out lightweight empathy maps for each interview to help others connect with each of your users, showing the rainbow of possible customers as well as the commonalities.
I tried this new approach to empathy maps last week and it was a huge hit. I was inspired by this Practical Guide to Empathy Maps, made some tweaks, and ran it with five interviews. This format took well less than 10 minutes to complete for each call, led to visually engaging notes that my team actually read, and made user research fun. It’s the best experience I’ve had with documenting user research, and I hope you have great results too. Here’s my how-to guide to making one.
Customize your maps
I’ve created a template map that you can use along with a script for calls. Create a copy of each to get started!
Choose a set of default faces for folks who don’t have a photo on LinkedIn (more on that below). I took pictures from a set of vector avatars.
Pick the demographic data you wish to track. This will populate the bottom of your map, and it helps if it’s visually engaging. I put:
User’s country’s flag
User’s company’s logo
User’s role at their company
Familiarity with our product (from 1-5 with stars)
Familiarity with our problem space (from 1-5 with stars)
Whether they’d buy our product as a big green check or red x
Research your user
There’s a lot about your user you can learn ahead of time! Look them up on LinkedIn to hopefully get their company, role, etc.
Add the user’s name and other demographic info to the map.
Grab the photo for the middle of the map. Here’s a clip of how to insert the image into the map:
Run your call, follow your script, and you’ll get all the info you need to fill out your map. Especially look for soundbytes to add as quotes to the map.
Fill out your map
Add it all in! If others joined you on your customer call, collaborate on the notes.
Save your map to an image, share it with your team, and print it out as a visual radiator on your team’s walls.
That’s it, and hopefully your foray into empathy mapping is a great success. If you’re working with a new Product Manager, this is also a great lightweight way to both think holistically about a customer interview and to enable quick note-taking and communication. And while you’re at it, you should acquaint them with the classic empathy map, which just got an update from XPLANE, as there may be something you want to borrow from that too.
It’s surprisingly hard to tell my kids what I do at work all day. Product Management is awesome, and I want that excitement to come through, but at ages 8, 4, and 1 it can either be too nebulous (“I help people by building great products for them”) or too exact (“I understand customers to build a vision and strategy for a product”). Recently, though, my family found an awesome board game that not only helps explain Product Management, but brings Product Management skills right into our house!
Engineering Ants is a cooperative board game from Peacable Kingdom. We love the cooperative games from Peacable Kingdom as they get us all working to win together. In this game, we’re presented with a set of random challenges that your ants must overcome, like escaping a wild bear or getting through sticky mud, with a set of cardboard widgets to connect to together to build solutions. The widgets are things such as batteries, sails, wheels, rope, and chairs. As a team you build a solution, and when you all agree it’s a great answer to the challenge, you move to the next one.
Right away the premise of this game teaches the collaboration and co-creation that are vital to Product Management. With this game you can show your family that being a Product Manager means taking a vague challenge and working with others to build a prototype or solution! The rules of the game are vague, which also means you can bring your Product Management toolbox of choice to demonstrate to your kids what you do all day. For instance, we’ve started using these house rules:
The challenges are vague, like simply stating a fallen tree is in the way of your ants. The player that reaches the obstacle must define the challenge and answer any questions the other players might have to help build the answer. This reflects how Product Managers may have to research a problem before helping others create a solution.
The first player picks two widgets to connect to start a solution, then passes it to the next player to add another, and so on until everyone has added a piece. This lets the solution evolve with each player getting to put their thumbprint on it, and echoes design thinking workshops of co-creation and ensuring everyone has a voice.
Once everyone has put a piece on the solution, we give a fist-to-five vote. If anyone is a 2 or under, they talk through their concerns and we alter our design. My 4-year old thinks this is a game just in itself, and is always very excited to give her vote! This is another great tool for Product Managers to judge alignment of a team around a solution.
The whole family has been loving Engineering Ants, and if you have young kids that want to know more about your job or you want to get them started on the path to Product Management early, I recommend you check it out too!
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!
At work, we regularly get our Product Owners and Product Managers together to discuss developments in our company and in the PM industry. This week we had a great conversation around Jeff Bezos’ recent letter to Amazon stakeholders, and below is a discussion guide if you’d like to facilitate the conversation at your company too! The letter outlines the top ways that Amazon avoids Day 2, (the gradual decline into obsolesce,) through true customer obsession, resisting proxies, embracing external trends, and high-velocity decision making. Our conversation was free-form, and many of these questions were covered naturally and asked by others, but it’s always great to have a set of backup questions ready to go to spark debate. Even if you don’t do a discussion group, I highly recommend reading the letter.
Quick Take – Go around the room
What did you think about the letter?
What was your top take-away?
What day are we on, Day 1 or Day 2?
True Customer Obsession
Do you feel we have true customer obsession?
How are our customers “beautifully, wonderfully dissatisfied”?
How could we highlight and lean into our customer obsession, or improve it?
Do we have any proxies? Could we avoid using them?
Do we have any cases where our process is the proxy for the results we want? Do we own the process, or does the process own us?
Do we have any proxies for customers?
How could we highlight and lean into resisting proxies, or improve it?
Embrace External Trends
What’s the last external trend we embraced?
Are there external trends that we should be embracing?
How could we highlight and lean into embracing external trends, or improve it?
High-Velocity Decision Making
What is our decision making velocity? High, medium, or low?
Do we have the right amount of decision-making processes?
Do we make decisions with 70% of the information?
Do we “disagree and commit”?
Do we recognize misalignment early and escalate?
How could we highlight and lean into high-velocity decision making, or improve it?
What actions and next steps should we take from this conversation?
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.