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.

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.

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.

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

Jessica 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
The 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