People – The Forgotten Metric

As a former Product Manager I was often asked about metrics. What’s your expected ROI? What’s the end user adoption rate for this feature? When we will break even? These are notably worthwhile metrics that are important for a product and a Product Manager to be aware of. Even so, these aren’t the only numbers a Product Manager or Product Owner should be concerned about.

As I was learning the ropes of becoming a Product Manager, I had a mentor who was very interested in measurements relating to the teams working on his products. He was often criticized and questioned why he was so interested in team morale and happiness and their skill level and knowledge. He was very active in motivating the teams. IT managers felt he was out of line and diving into territory beyond his concern. This often caused some rifts between my mentor and the IT department. I finally asked him one day why he took such interest in these metrics and ensuring the teams were so happy. He simply stated, “Their happiness is directly related to the success of my product. Why wouldn’t I want to be interested in that?”

He felt that no matter what new product or feature idea he brought to the table, the product would fail if the teams weren’t happy and engaged. He needed to assess whether the teams were ready and capable of delivering. He needed to know if there would be retention problems, loss of tribal knowledge or missing critical skill sets, etc. If there wasn’t a team available and excited about working on the product, chances are the product wouldn’t get built well or at all. His product relied heavily on the “the people metric.”

I really never thought those types of metrics were important for a PM. I always knew end user, customer and financial metrics were highly important to a Product Manager. Yet I never considered team and process metrics being something a Product Manager would look at. That was something for IT managers to handle. Working with my mentor opened my eyes to a larger pool of metrics that I had overlooked and potentially an underlying factor for some less than successful ventures. Products don’t require a lot of metrics to ensure success. What they do require is the right type of metrics.

One point I didn’t mention before is my mentor was previously in a situation where many skilled team members were very unhappy with the project, the vision and overall reason behind these new features. They considered leaving the company which they did right in the middle of a critical point for his product. As a result, he missed a great market window and the project ended in failure. The unhappiness of the team members blindsided him. He had no idea things were in such a state of disarray. This was the beginning of him focusing on the people metric.

When choosing metrics for your product, don’t forget the people building it for you. Include one or two metrics that focus on people and process in addition to market, customer or financial metrics. Monitor the teams as much and as often as you monitor customer and end user happiness. It is most definitely the responsibility of a Product Manager. In some ways, the teams are way more important than the people using the product or the stakeholders sponsoring the projects.  Remember, being a Product Manager is the closest you can get to owning a business without actually owning one. This means you have to have a 360 degree view around your product and manage it as though you actually did own it. Act like the people building your product work for you and success will be around the corner for you and your product.

What to do when your daily scrum looks like a status meeting?

I recently took on a new scrum team. For the first couple of weeks I observed all of their scrum events sitting quietly in the back of the room. I wanted to see where the team was with their agility journey and what places may need some firming up. What immediately jumped out to me was how they were practicing their daily scrum. The scrum master I was replacing called on each person to talk. The team proceeded to tell what they did yesterday, what story they were going to work on today and ended with “No blockers”. They all talked to the scrum master instead of each other. The scrum master wrote down notes and asked questions about their statuses and delays.

After the daily scrum, all I could tell was that 4 or 5 stories would be worked on and that yesterday 4 or 5 stories were worked on. I had no clue if someone could help anyone else or if there were going to be any conflicts with the work they were doing. The team felt because everyone was working on their own separate thing, there was no need to share more details about what they completed or would work on. The team failed to see the value in discussing more because no one else would be able to help with their work due to lack of product knowledge.

I contemplated this situation and wondered how I could get them to see the value in providing more information about what they are working on to each other. I decided to create a couple of videos about construction workers working on a house to demonstrate how even when people are doing separate, discrete work it’s important to share a bit of the details so they can plan with each other. In my videos, there is a carpenter, an electrician and plumber working together to build a house. Each is only capable of doing work within their trade and there isn’t much overlap between each profession. In the first video the construction workers conduct a daily scrum like a status meeting. The second video shows how it might go if they used the daily scrum to actually plan the day’s work.

After showing the videos to the team, we had a lively discussion about the differences between the two. They started to see how they could actually learn from one another and get help when help wasn’t obvious. Of course there were still some skeptics, even so the possibilities of more collaboration was in motion. My first change was to stop calling on people to speak. This violated self-organization and empowerment. They decided who would speak next instead of being called upon by me. The next change I implemented was for them to “pretend” I was on vacation so they would have to conduct the daily scrum without me. I stood in the back of the room and let them take the lead. It took a bit for them to decide who was going to show the scrum board for the remote people and who would get the conference line going. Once that was decided, this simple change immediately showed results. There was more conversation than ever in the room. Ideas of how to help others with their work flowed and developers participated more by asking some poignant questions that gave some good insight.

I learned that it doesn’t take big changes to shift thinking. Small little things can make an enormous shift for a team. In this case, I met the team where they were, determined what a step ahead would look like and then jumped into action with small, minor adjustments. Sometimes it’s better to think small in order to make large changes. While some are still giving a status update rather than focusing on planning, others are shifting how they talk in the daily scrum. It’s a process and we’ve made progress towards improving our agility journey.


What Emotion Does Your Roadmap Bring?

One of the many artifacts a Product Owner is asked to produce is a roadmap for their product. While the strategy tells the high level execution plan and the vision depicts what the product will eventually look like, the roadmap basically tells how the product will get there and approximately when. Pretty straightforward right? Well…not quite. Putting the wrong information in a product roadmap can cause a lot of turmoil for you and your customers. It’s important to provide the right information in your roadmap to generate excitement not anger. Roadmaps are just that, a map of the road the product will take to evolve, grow and mature. Too much detail in a roadmap can cause a lot of havoc as it did in one of my previous jobs.

A Product Owner in my former company developed a roadmap for his product that was very specific and highly detailed. It gave information specifying the exact capabilities a feature would possess and the exact date these new capabilities would be released. He communicated this information not only internally but externally too. Of course, as with any project, things happened where the team could only produce a small set of the promised capabilities. Other capabilities had to wait for a later release….much later release. And because we weren’t practicing agile, the capabilities delivered weren’t necessarily the most valuable ones. When we failed to deliver those valuable features on time to our customers, they  became highly upset and started to lose faith in our product and company. The major mistake made here was providing too much detail in the roadmap. And of course not practicing agility to deliver value didn’t help either but that’s a topic for another discussion.

What could have helped here was using a roadmap with just enough detail to get our customers excited about our product rather than fueling their anger. To avoid the “you didn’t deliver these things on this date” problem, use approximations rather than specific dates. State you expect a feature to be released between Q3 and Q4 or even during a season such as summer or winter the following year. Don’t specify exact capabilities that will be delivered. Get your end users more excited about what new value they will receive rather than when they will receive it. Be careful though. You don’t want to wait too long to deliver or they will lose interest. If you’re skeptical about avoiding specific dates, here’s an example for you.

In the spring of 2017, it was announced the release of the video game Red Dead Redemption 2 would be delayed until the spring of 2018. I was really looking forward to its 2017 fall release. Notice the game’s original release was specified for a time of year, fall. No specific dates were provided and the new release date is in the spring. Again no specific dates. Even though there is a delay in releasing the game, I’m so excited about the game itself, I really don’t mind waiting til next year. Despite the fact that it would have really been an awesome birthday present this year! Even so, I don’t know exactly when in the spring of 2018 it will be released. I just know early in 2018 I get to pretend to be a gunslinger in a whole new western adventure. Wouldn’t you rather have this feeling of excitement in your customers than creating a roadmap that makes them angry with you and likely to purchase something else instead?

Finally, review your roadmap regularly based on the product and market maturities as shown below. Constant review of your roadmap will ensure you and your teams are working on the right things and quickly communicating changes.

Roadmap reviewDiagram courtesy of Roman Pichler

I can say when we incorporated the approximation roadmap approach and reviewed our roadmap frequently according to the product and market maturity levels, we improved our relationship with our customers and our internal staff. We were able to fulfill our goals of delivering features and came closer to hitting our revenue targets. No matter which type of roadmap you choose to use, use one and be vague on purpose about release dates. Your roadmap helps you reach your destination by minimizing frustration, detours and wasted time or effort you’d experience without one. Done right, it keeps your customers happy with anticipation of your upcoming product release.

Can’t See the Future without a Vision

I recently worked with a team which constantly asked for the product vision. Leadership happily provided it and held several group sessions to do so. While Leadership was reveling in their ability to accommodate the request of the team members and demonstrate their servant leadership, the team members where huddled around privately complaining how leadership presented a strategy and not a vision. This cycle of presenting a strategy rather than a vision by leadership went on for months finally resulting in both sides getting very frustrated with one another. Despite the Leadership’s efforts to provide a vision to the teams, the team members were still at a loss for what they were trying to build.

Leadership was angry because they didn’t understand why teams weren’t getting it. The team members were angry because Leadership wasn’t getting what the team wanted. Does this situation sound familiar? Vision and strategy often collide where one is thought to be the other. A strategy is high level and explains how you plan to execute or realize the vision. The vision is the REASON behind the product such as “I want to promote teenage health” or “I want at risk kids to believe they have a chance to go to college”.

Teams need a vision so they know how to proceed forward and to feel confident they are making the right decisions at a lower level to support the future vision for the product. When the vision is sketchy and a bit muddled, the possibilities are endless so they wander around wondering which one to shoot for. Teams need clear direction on which possibility they need to strive for. You can imagine if someone came to you and said, “Build devices to transport people anywhere” how difficult it would be to know where to begin. You may understand the importance and why but you don’t know the ultimate vision. Is the vision to capture the outer-space market? That may require some expensive equipment, materials and specific skill sets. Or is the vision to make travel on earth easier?

A vision should create a picture and ignite emotion and excitement. For example, “Our vision is to disrupt the transportation industry and allow people to travel instantaneously without the need of an automobile or plane.” What vision did you just create in your mind? Was it the same as the one you thought of when you read the vision of building devices to transport people anywhere? Which one created more emotion, excitement? Without a vision of what the future will look like, strategies, roadmaps and business value means nothing to teams building your product.

If you’re a Product Manager and you want your teams to understand your vision and get behind it, ask them what they are looking for in a vision. Translate your existing vision if necessary so they understand it and can get excited about it.  It’s much easier to build products when you have an idea of what the future of the product may be. Don’t underestimate a good vision and its impact. Also don’t confuse vision with strategy. Remember, your vision is the foundation that supports the future. When people can embrace and see the vision in their minds ideas, thoughts and enthusiasm flow effortlessly.

Avoid Product Liposuction

One of the biggest mistakes a Product Owner can make is to want it all. I’ve heard Product Owners say, “We need all these features and nothing can be omitted.” My first reaction to this statement was “Really? NOTHING?” Product Owners commonly fear taking away features from clients or not giving the client everything they asked for. As a former developer, I often wondered what type of customers or users would require everything the Product Owner was asking us to create. Some features or capabilities just didn’t seem worth the effort it would take to build let alone maintain them. Others didn’t make sense that a client would even want them. If your product owner is making this type of statement and more importantly pouring on more questionable “must haves,” then you need to sit her down and explain to her the pitfalls of having a morbidly obese product that will eventually need liposuction to survive.

One of the core problems with making a product fat with “nice to haves” is the cost and time to maintain those features. Any time a new feature is added, developers and testers must account for testing ancillary code on lessor used features impacted by the new request. Regression testing as well as potentially breaking other areas is increased. These necessary activities to ensure product quality take time, effort and money. When developers and testers are focusing on ensuring less valuable features stay intact it takes away from implementing new and more valuable features. So as the team builds all the “must haves”, the product becomes obese and complex to maintain with little room left to build muscle…you know the features and capabilities that strengthen the product. Quickly the product becomes inflexible and unable to scale without huge risk and cost. The ability to get features out to the market quickly vanishes. The product becomes a liposuction candidate for excess fat removal to allow for muscle growth.

Product Owners, listen up. There are times when even a highly used feature could be replaced with something more valuable or modern. Learn what problems the end users really have and what features they use, don’t use or truly need and why. Often end users get complacent and believe an invaluable capability is necessary when really their needs have changed and evolved without them knowing it. Your product must evolve beyond what your user base believes is critical. That means letting go of features to create room for new muscle. If you’re squeamish about this idea think of the iPhone 7.

Apple took away, what many considered a highly valuable feature, the headphone jack. The removal of the jack allowed for a thinner phone with a wrap around screen. The benefit of a smaller, lightweight phone with more screen space was greater than having an embedded headphone jack. Additionally, the new approach to connecting audibly with the iPhone 7 brought greater quality sound than before. Definite added bonus. So, before you make that statement you need it all, think about your product diet, its fat and the amount of muscle your product contains. Avoid product liposuction by focusing on features which help create product muscle (aka the features that matter to your clients). Don’t let your product consume empty calories or “must haves” which only create a maintenance, testing, development nightmare for you and your development team. Focus on creating products that your customers will really want and can use to solve their future problems instead of products that are full of useless fat that solved last year’s problem.