My Path to a Growth Mindset & 7 Tips to Help You Acquire Yours

IMAGINE walking into a company where teams have been engaged in Scrum or Kanban for a few years. After careful observation you discover teams are practicing the mechanics of these frameworks but are still struggling to embrace the spirit and intent of them. If teams or organizations aren’t practicing the values or principles of an agility framework then they have one foot stuck in a waterfall world. I use to wonder why so many places seem to implement agile frameworks yet still work in a waterfall manner. Even though scrum is relatively simple and can be explained in about 10 minutes, it still seems to be very elusive. It wasn’t long before I realized the reason why companies struggle so much with agile.

Bottom line, without a growth mindset, agile won’t work. It’s critical to its success. I would argue it’s the #1 reason why agility transformations fail in organizations. Teams AND Leadership must possess this mindset. If not, the company is misaligned and agility falls flat. A growth mindset is the most difficult thing to acquire if you don’t inherently possess it. It can’t be easily taught and not everyone is equipped to teach it. It takes hard work and lots of practice to develop. If you have a fixed mindset you probably think you can’t acquire a growth one. Well it IS possible. I had a very fixed mindset at one time and I was able to shift to a growth mindset. I was a negative “it can’t be done because…” type of person. I always saw how things would fail. I’m far from that now. I’m completely the opposite. In fact one of my recent direct reports once called me “disgustingly positive”. How did I change? Well, let me share my transformation journey with you.

My first managerial position is where my journey began. I was offered a position to manage a team of business analysts which eventually expanded to include tech writers and user experience designers. I was very excited about taking on the role. I immediately ran out and acquired any information that could help me make the leap to becoming a manager. I read books, took a company online course, consulted with others who had made the switch and talked with seasoned managers for advice. When I went into the position I felt I was ready for it. Shortly into the role however things went astray.  A former BA myself, I worked with the developers my team was now engaging. I felt since I had a long relationship with the developers, I knew what my team needed to do to be successful with them. I would specifically tell my team what actions to take and how. I reviewed their work and gave them feedback which was mostly negative and filled with promoting my solutions. I never even gave a simple “Nice job” to them. I totally believed I was helping them succeed. I was removing the obstacles I believed they had and giving them the tools they needed to succeed in our environment. Then one day out of the blue my boss called me into his office. He told me he met with my team and had feedback to share.

Thinking I was going to get raving reviews, you can imagine how devastated I was to learn my team hated my managerial style. They even called me a micro-manager which made me shutter as that was something I never wanted to become. As my boss gave me the feedback, I made excuses and became defensive. I explained how I was helping them and my communication style though blunt and direct was honest. He continued to provide more feedback but I had stopped listening at that point as I was fueled with anger. My hearing perked up though when he finally said things were changing and I may not have a team to manage if I didn’t turn things around. My heart sunk. What was I going to do? Fortunately for me, I had a friend who was just starting a coaching practice. She offered to coach me through this. She first coached me on empathy and emotional intelligence. She was able to get me to understand that words invoke emotions and I need to be more conscious of “what” I said over “how” I said it. She recommended I read the book “Crucial Conversations” to help with my conversation style. It was a hard road – an analytical mind learning about feelings?

The first time we role played, I got very frustrated. Every time I used a word, she explained the negative emotions it could ignite. In less than 5 minutes I ran out of words to use. I became so frustrated I wanted to quit. She never gave up on me though. Despite my frequent “quits”, I stuck with it. I felt awkward and uncomfortable. My communication became disjointed and unpolished. I had a lot of missteps and mistakes. I kept practicing. Slowly I began to think about things in a more positive way and my conversations improved. I took the “opposite” approach to ask questions and to use more positive words. When negativity rose in my mind or conversation, I tried to think of one thing that was positive and I focused on that. When someone said something couldn’t be done, I asked “What would we need to get it done?” I started to listen closely to words and tone of voice and noticed facial expressions. This led to realizing when empathy was needed. When the urge to explicitly direct my team on what to do surfaced, I repeatedly told myself “My way only works for me, help them find their way. Leave your ego behind”.

Within 3 months, I turned it around. My team reported to my boss things were tremendously better and I was providing the support they needed rather than the support I wanted them to have. My boss said he didn’t know of anyone who could have turned things around so quickly. My command and control, fixed mindset was starting to vanish. Yet my journey was only beginning. I still had a ways to go. I often slipped back to fixed mindset and my blunt communication was still present in certain situations. I had more to learn about conquering negativity and growth mindset. So I decided to embark on a learning quest to study more about positive thinking. I read many books (which I recommend below) to continue my mindset transition. I practiced techniques with family and friends. I learned to let go of my ego more and focused more on others and their needs. I created a list of “messages” to tell myself when I slipped back into fixed mindset. I planted the seed in my brain, “I’m just a companion on someone else’s journey; enjoy the ride and help when I can”. I visualized what others with a growth mindset would do.

My journey to growth mindset was by far the most difficult thing I have ever done in my life. Despite the pain, anxiety, and frustration I went through…it was worth it. I’m not “cured” by any stretch. I still fall into fixed mindset on occasion. But now I have the tools to quickly emerge from it. I know how to manage it before it does any damage. Growth mindset is the foundation for servant leadership. I needed to acquire this mindset to become a good leader, scrum master and coach. Hopefully by now you can see why mindset is so important and also why it takes a backseat in training sessions. If you don’t have the growth mindset know that it can be achieved. Here are some tips and recommended reading that may help you find yours.


  1. Get some coaching – My mindset would not have changed if I didn’t get some career coaching. Changing your mindset is hard and requires outside help and support.
  2. Be patient – It will take time and you will fail, feel awkward, be stretched way out of your comfort zone and feel like quitting multiple times. Don’t quit! You can get through it.
  3. Acquire a support system – Look to others to help you. Practice with family and friends. Tell them what you’re doing and why. Ask for feedback about how you made them feel and where you may have dipped into the negativity pool.
  4. Continue to learn – Read or listen to as many books, articles videos as you can. Explore what creating a mindset means and how to keep it. Find people who already have the growth mindset. Watch them. Learn what they do and how they handle situations.
  5. Develop a toolkit – Create messages, phrases, rituals, etc. that will help you when you enter into a fixed mindset. Repeat them over and over again until it becomes a habit for you to use them.
  6. Find the positive – Even when something seems so bad, if you try hard enough you can find a small little bit of positivity. Focus on it and use it to keep the conversation and yourself above the line.
  7. Change your lens – Look at things from all different angles or the opposite of how you normally looked at them. Try to find ways you can grow in a situation rather than ways you can’t improve. Take action on your discoveries to facilitate your growth.

Recommended Readings/Videos:

“Crucial Conversations” by Kerry Patterson

“Miracles are Guaranteed” by Bill Ferguson

“Mindset” by Carol Dweck

“Drive” by Danial Pink

“The 5 Levels of Leadership” by John C. Maxwell

“What Got You Here Won’t Keep You There” by Marshall Goldsmith

“Emotional Intelligence 2.0” by Travis Bradberry

Above the Line Thinking” by The Consciousness Leadership Group

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.