guest blogger product management

The Worst Nightmare of Any Product Manager

Guest Post by: Liel Aharon (Mentee, Session 4, The Product Mentor) [Paired with Mentor, Felix Sargent]

adelorme_11[1]

At the end of 2015 I was in the worst nightmare of any Product Manager.

I had a strong roadmap, clear goals and a vision for the product. The team had been working for almost a year and had a huge amount of code under their belts. We would regularly meet to discuss the features required, what the customers expected. We were making great progress. But just because it was a lot of code doesn’t mean it worked. In fact, our tests regularly failed. The relationship between QA and Engineering was bordering on food fights, and we’d only achieved half of our requirements. A production release was a distant vision.

As we were getting closer to the end of the year, my senior vice president called me in, to review our progress against our goals. He asked me to provide a status of where we stand, and wanted to make sure we are on track to deliver on time and get our bonus.

Oh crap, no way we could deliver on time I thought to myself.
How did I get here?

It wasn’t one thing. There were a variety of different problems, and symptoms. We’d made great code. We had good production standards. We were Agile, with daily standups, two week sprints and detailed estimations. We were testing our code. What did we lack?

Focus.

I thought if we’re already doing one thing we might as well also another, or just fix this thing as well. When we were working on creating the edit permissions group for apps, we also decided to work on the internal permissions that will be used by the team that supports the Appstore. Similar, right? Should be an easy fix. Wrong.

I’m not a technical Product Manager. I knew that I couldn’t look into the code to see that our engineers had built what I was looking for. I felt I had to wait until a feature built out before I could give my feedback.

We were doing Agile. We had a daily standup, sprints and estimations. But with nothing to ship, were we? Did it matter? Was it my fault?

My Senior Vice President needed an answer. More “Context and Direction”. We needed to deliver in three months. What could we salvage?

“From now on, only our most critical stories will be completed as part of V 1.0.0.”

If we were going to ship in three months, we had to figure out what we were shipping. Two sleepless nights, eight shots of espresso and one bottle of wine later, I worked with the team to have a plan. We were going to focus on making the most crucial api call to create apps work, the rest we decided to change through direct db access at first.

Once we were able to define what  V1.0.0 was it was easier to break down the issues into small stories. Prioritizing between stories got easier, because we know what they were.  The result of it were clearly scoped versions, that last about 2 weeks for development, testing, and validation.

When the team started working in shorter cycles, testing was simpler, and they could get my feedback quicker. I had the confidence to test new features to make sure we are building in the right direction, and engineers felt on track.

Finally I was able to breath.

After going from a long development process to a shorter cycle, we have managed to resolve our most glaring problems. We managed to decrease each dev-test-release cycle from being months to 2 weeks. Was the problem Agile? Or were we just not doing it right? It’s easy to confuse the rituals of Agile with actually getting things done.

If you are having similar problems with your development process I highly advise you to analyze the reasons to them, starting with an honest answer to the question – is your process actually solving your problems?

 

About Liel Aharon
LielAharonLiel (pronounced as Lee-L’) is a Product Manager at MediaMath, the marketing operating system, and is the Product Owner of the company’s Appstore. Before that she held multiple positions in Fin-Tech companies in Israel as Associate Product Manager, Project Manager and QA Engineer. Her Computer Science with a major in Entrepreneurship along with her past experience is giving her a unique point of view with a let’s get this done attitude. When not working Liel can be found adoring her Boston Terrier puppy, or working on another home cooked meal with a paired cocktail.

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