So, your boss’s boss walks into your office and changes your roadmap…

Guest Post by: Jessica Waite (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Radhika Nayak]

So, your boss’s boss walks into your office and changes your roadmap…

No, this is not a bad joke.

shutterstock_222658030[1]

As a product manager you prep, plan and execute. You spend months in discovery carefully understanding the customer, the business needs, the software requirements and how to execute it all. Once you discover what the root problem is, you lead a team to making the solution a reality. In my case with my product, I knew the main problem when I started. The problem was an unstable code base that supported (if, and when it worked) all of our internal tooling. The only real solution was to rebuild everything from scratch; requiring phasing out the old platform and creating a new one and managing multiple products and roadmaps. Product 101 was key: understand the stakeholder’s problems,  customer needs versus wants, and making informed, strategic details for feature roll out, and ensuring what you build will scale.

We knew from the start  a better solution to our collapsing software would be a huge undertaking. One of the main things I learned this year was the importance and execution of phasing out products. It’s important to continually question priorities, identify solid wins, and develop a realistic timeline. Anyone who has worked with software knows, you can not just stop development and bug fixes on a current product because you know you are building something new. The platform we were replacing still needed to work until it  all of its core functions were in  the new code base.

Time is the most valued asset but it is in most cases not on your side.

time-management[1]A product manager sets expectations appropriately while maintaining a level of transparency but this can be extraordinarily hard to do. To properly set expectations you have to understand the problem and become an expert in how the product will be used, and how it should work long term. Setting expectations early on depends on having enough information to actually get it right. The tough part is once someone knows you are trying to fix or build a solution they want to know when they can have it. If you don’t know the scope of the issue you can’t solve the problem and you can’t give a realistic answer. While doing phase one of document storage and planning out the execution of the next phase and overseeing the maintenance of the old platform, I was asked if I could rebuild our ticket management system for ads in three months and in doing so move my next planned phase till after I could deliver ticketing. The person on the other end of this question happened to be my boss’ boss.

As humans we have a deep desire to have all the answers especially to someone who is in a higher authoritative position. So you can imagine my stress when this was asked, my new knee jerk reaction was to say yes in order to sound “informed” but in reality that wasn’t planned for discovery for another six to eight months. I had only been at this company for six months and I knew that ticket management was a huge build. My response was, “That sounds like a very aggressive deadline, I can not confirm that until I do some research. I will get back to you after I have had some time to scope this out.”

When you are trying to investigate a problem you need to not only identify your stakeholders but you need to be efficient in getting information. You move quickly to find out what you didn’t know. One of the biggest time sucks for me initially was inefficient meetings. Through talking with my mentor, I found that it is best to keep your meetings with stakeholder small, no more than four or five people in the room. Give them an agenda of what will be covered in your meeting ahead of time. The agenda will help all stay on task and maximize your time together. And if you have good stakeholders, you will be able to identify quick wins that will boost moral as well as the harder to tackle underlying issue. Had I not been allowed this time to properly scope I wouldn’t have had enough user centric information to think this problem through and start phasing ticketing.

Epi-201-M2M[1]

Had I just said yes initially I would have failed in meeting the deadline because I didn’t fully understanding the massive undertaking that was ticketing. I would’ve also failed as a manager because I wouldn’t have known that I needed to hire more people to execute so we could deliver quicker. Discovery alone took three months. Having the old platform as a cautionary tale of being built without scaling in the future in mind, I wanted to solve this and provide a sustainable solution. I initially thought ticketing was made of a few components, a couple forms and one or two workflows. It turns out it was over 35 forms that were riddled with conditional logic, a redundant backend ticketing system, several dashboard views and needed to cater to a myriad of job functions. There was no way that I could have done this just my original team in the initial time asked. I needed to be in the room with with stakeholders, hire another dev, and work with a designer who could establish a pattern library to ensure consistency across the  new platform. Additionally, we weren’t just going to be duplicating what had originally existed, I had to improve it by coming up with a more efficient process and workflow to save the company time and money. Those were all things I needed to identify before I possibly committed to a delivery date. In the end I kept the trust of my upper management because I was transparent, and I didn’t miss a deadline that was unachievable.

I have found in my six months in The Product Mentor Program when you focus on building something that scales and solves the needs of your company by being driven by customer needs, that you have to be all in in order to really solve big problems. This is a hard job but we have a community of brilliant people who have been where you are and are willing to help. The tools you use can definitely help but it is the strategic planning of your phases; learning how to constructively set expectations of both your role and your team; and investing a piece of yourself into the company and your product are what make a good product manager. Even when your roadmap gets changed quickly because of company needs, you will be alright as long as you have established a good cadence of steps to execute

About Jessica Waite 

5p6 - jessicaJessica Waite a Technical Product Manager at Townnsquare Media in New York City. She is currently working on rebuilding all internal tooling for TSM from the ground up. Learning from the prior code base she has implemented new, more efficient workflows, to ensure all around smarter tooling that is focused on the long term scalability of her newly developed product.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Advertisements

Driving Product Priorities with a Stakeholder Roadmap

Guest Post by: Marc San Luis (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Dave Skrobela]

In the education-technology sector, there is one hard-set deadline. That deadline is simple: you must release a working product before back-to-school begins. Period.

When I returned to the Ed-tech sector a year ago, I joined a team with a very aggressive goal. The goal was two years in the making. It was to create a new online education platform and then transition the newest versions of digital product offerings into that platform. All of this must be launched before the 2016 back-to-school season.

I was brought in to head the Data and Reporting platform and eventually started to take on more responsibilities as a product owner of the Teacher platform. One of the biggest challenges I encountered was the overwhelming amount of features my team had to deliver.

201tickets[1]The backlog was growing and the deadline looming. It was at this time that I joined The Product Mentor and was teamed up with my mentor Dave Skrobela. Dave’s experience in the Ed-tech industry was very helpful. We went on to discuss a game plan on tackling my problem: managing and prioritizing the product backlog with these hard-set deadlines.

In order to properly prioritize the backlog, one of the lessons I learned from my mentor is to fully map out the stakeholders. Stakeholders are anyone who has a deep interest in the product. These are the people with direct or indirect influence in the product. It could also include the actual team creating and executing the development to finish the product.

The best way to map out the stakeholders for a product is to build a stakeholder map. A stakeholder map is the best way to document all stakeholders in every project. This map can be used to better inform the prioritization of the product backlog.  

I started my stakeholder map using the template provided by my mentor. However, this stakeholder map template should work for many product owners regardless of the product or the field they are in. The stakeholder map is a matrix that contain every stakeholders that affects the product.

We started the stakeholder map with first listing all the stakeholders we have in mind and grouped them based on whether they are internal vs. external stakeholders.

The best way to figure out whether a stakeholder is internal vs. external to your project is using the following analogy of “The Chicken and the Pig.”

Image result for chicken and pig

I first heard of “The Chicken and the Pig” analogy the very first time I went to an Agile seminar. This analogy does a great job in describing stakeholders in your product and it has to do with gauging stakeholder commitments.

Think of your product as a dish of ham and egg that you ‘cook’. The “Chicken and the Pig” analogy goes something like this: when cooking this breakfast dish of ‘ham and egg’, the chicken will provide the eggs, however the pig will provide the ham of the dish. In this analogy the pig then is the most committed while the chicken is only ‘involved’ in your product.

The chicken is then synonymous with the external stakeholders of your product. They may be the marketing and sales team, the technical supports team, or even your boss’s boss. They care about your product but they are not going to be the one burning the midnight oil to get the product to launch next week.

Internal stakeholders then are the people more directly involved in executing or creating the product. They could be the U/X team or designers and web developers that are in-charge of deliverables that must be made to complete the product.

Once we have listed out all the internal and external stakeholders, these will divide the stakeholders into external vs. internal stakeholders.

image

Figure 1.0

Mapping the stakeholder map in this matrix is very helpful. It shows a clear way of figuring out exactly who or whom we need to listen to, answer to, or work with to prioritize the product backlog. The map is organized into columns. See Figure 1.0.

The first column will of the stakeholder map lists all the stakeholders. The next column we added the ‘Initial Release Impact’. This was an important column for our project to help the team figure out the stakeholders we need to keep in mind to help with the initial release of the product, the people that will help market, support, and troubleshoot the product during launch.

Again, the columns of the stakeholder map can be fully customized based on your needs. However, this exercise is truly vital in figuring out every stakeholder that could impact the project, how the product backlog must be prioritized, or even highlight the people that we must keep in mind as we execute the project.

In our case, my mentor and I focused on fully fleshing out two stakeholder groups. The first is the direct team that will help in the execution of the project. The other is the marketing team that eventually interacts with the customer and also market product features. The next step after we have honed in on these two teams we wanted to focus was to gauge the stakeholder’s level of influence. We decided to create a proper channel for us to focus on these groups via the creation of a ‘Communication Plan’ which is the second step after creating the stakeholder map.

Communication Plan

The communication plan is simply a document we created to figure out the pathways of communication with the stakeholder. This is important in order to fully open this channel of communication with the stakeholders and to set a more consistent plan and timeframe of communication.

business-planning-653x339[1]The communication plan could essentially be a communication mission statement that we created to ensure we facilitate communication with the stakeholder.

In regards to the marketing team for example, I quickly realized that I did not have a way to fully talk to the marketing team directly. The team travels a great deal, and so I resorted to talking to my boss about this concern. My boss was indeed good and mindful about this and he has started looping me into any marketing communication and updates.

We started creating Powerpoint slides to ensure we communicate the upcoming features for the product to the marketing team. In addition, we receive feedback about customer needs as well as ‘marketed features’ that must be released to fulfill customer expectations.

In addition, we are doing our best to extend the sprint demo to the marketing team. Although they are not always available to attend these meetings, they are able to figure out exactly what features are ready to be demoed and often times requests a one-on-one demo. In addition their feedback has been valuable to help my team and I to negotiate, prioritize, and process the product backlog in order to meet the deadline with aligned expectations.

About Marc San Luis

5p9 - Marc_SanLuis-photoMarc is a technologist passionate about education, he currently works in the ed-tech industry as a product manager. He lives in Jersey City and was a former president and current member of the Board of Directors of the SJI Association, a Filipino-American association based in NY/NJ. On his weekends, he loves studying Mandarin as well as reading and writing short stories.

More About The Product Mentor
TPM-Short3-Logo4The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy

Great Mentors and Mentees in Product Management

TPM-Short3-LogoWe recently just held the global Session 5 closing for The Product Mentor where everyone shared highlights of their experiences and what they learned.  All the mentors and mentees did a great job over the past 6 months.  Some exciting stats…

  • 80% of all OKRs Completed (Mentee’s Goals for the Session)
  • 4 Mentees Promoted
  • >60% of Mentees had career progressing conversations with their C-Suites

I would also like to take this moment to recognize those Mentors and Mentees that learned, engaged, and achieved above and beyond:

TPM-Mentor-Award

Awarded to Mentors for going above and beyond in experience, attention and accomplishment.

jordanbergtraum-crop[1]

Jordan Bergtraum
Product Management Consultant
Talk(s)​: The Benefits of Being Responsible for Product Messaging, Users vs. Thought Leaders, Introducing Product to Your Organization
​​​​LinkedIn

TPM-Mentee-Award

Awarded to Mentees for achievements in learning and advancement within the field of Product Management.

jessica-crop[1]

Jessica Waite
Technical Product Manager, Townsquare Media
Article: So…Your Boss Changes Your Roadmap (coming soon)
​​LinkedIn

peyvand-crop[1]

Peyvand Mohseni
Senior Product Manager, WANDA Inc.
Article: Know the World Your Product Lives In (coming soon)
​​LinkedIn

Receiving these awards is truly an outstanding achievement of which everyone recognized should be very proud.  Please reach out and congratulate our latest Mentor and Mentee inductees. (hashtag: #tpm)

Thank you again to everyone who participated and looking forward to more great achievements with our new Mentors and Mentees in Session 6, kicking off this January!

Jeremy Horn
The Product Guy

About The Product Mentor

The Product Mentor is a program designed to pair Product Mentors and Mentees from around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A

Signup to be a Mentor Today!

Throughout the program, each mentor leads a conversation in an area of their expertise that is live streamed and available to both mentee and the broader product community.