As a Product Manager, I often describe what I do falls into 4 or so buckets:

1. Strategy:
   1. High-level: Where should the product be going?
   2. Low-Level: What is the next thing we should build that will help us get closer to our goals/target?
2. Execution:
   1. Discovery: What is the exact problem are we trying to solve and what is the outcome we want to achieve?
   2. Delivery: How do we build this solution we “discovered” during the Discovery phase?
3. Analysis: Did what we design and build during the Execution Phase solve our users problems and bring us closer to our goals? Why or why not?
4. Support: How can I help the rest of the organization? This includes working with Customer Success to help them understand the inner workings of new features/processes, and working with Marketing to educate our customers on these new features/processes.

I strongly believe that a Product Manager who cannot execute is not a Product Manager. You may have the great ideas/strategy but if you cannot work with your product team to validate the idea, build it and ship it, then what’s the point of having all these great ideas?!

I also believe that we’ve greatly improved our Delivery Process over the last 10-20 years. We now use some version of Agile with Scrum, Kanban, Sprint Planning meetings, etc. to break things up for the Engineering team, and most organizations deliver on at least a weekly basis or are hopefully moving to Continuous Integration and/or Continuous Integration.

The Analysis aspect is also easier than before. We can use services like MixPanel, Kissmetrics, and Amplitude to see what actions our users are doing, then create dashboards to understand trends using Periscope and Chartio.

What I’ve felt we’ve not yet effectively conquered as a disciple/profession are the Strategy and Discovery aspects, which are the most critical for any tech team since they help you avoid building crap.

Strategy is something I’ve recently started diving deep into so at this time I do not have a strong viewpoint to share, but I can share with you on how my Discovery process has changed over the last 3.5 years of being a Product Manager.

Couple things to note before we continue:

1. I am not taking credit for coming up with any of these processes. Some were in place when I arrived while some I helped shape.
2. These version numbers are arbitrary in a way; I grouped certain things together depending on when I started at a new company or when we found a process that worked for some timeframe.

Not sure what Discovery is or what some more detail, take a quick look at this post before continuing.

Let’s jump in:

v1 – Gantt it Up

My first position was in a department that worked with clients, and when you work with clients, you then to have deadlines you need to meet.

As a result of being in a deadline-driven environment, Gantt charts were the tools of choice to ensure we could adequately plan our times and resources to deliver on time.

We tried to be as “agile” as possible where we broke up features into sprints, but at the end of the day we were still doing Waterfall as would do requirements gathering, then design, then development, and launch everything together at the end.

This approach had some consequences:

1. Missed Deadlines – Since we are doing so much planning before we even jump into any actual product development, our estimates were just guesses. So as things slipped, so did our deadlines.
2. We missed the mark – Since we heavily invested in building 100% of the feature, if users did not adopt some of the features then it was too late to scrap the feature as we already had spent weeks and weeks designing and building it.

v2 – Research, Iterate, and no more deadlines

At my last position, I finally found a place we were doing product development in the right way!

Product Managers heavily concentrated on researching/validating the problem before bringing in design and engineering, and once we found it was the right problem to solve, we then built the smallest solution to test whether our users would do what they say and use the feature.

Once we found success, we could then layer on more functionality that covered more use cases.

If the feature was not a success, we could then examine what went wrong by looking at metrics and interviewing customers, kill the existing solution and start again.

Also, since we did not believe in Roadmaps (which explicitly or inexplicitly provided deadlines depending on your perspective), we could eliminate that stress factor and concentrate on making the right product.

“v2” of this research/design process brought some welcomed benefits:

1. We could spend time thoroughly understanding the problem before building.
2. We could build the smallest solution first to test the waters before committing more time and resources to expand the solution. This way of working gave us the confidence to continue working or an early red flag that we missed the right solution.

However, there were some downsides.

1. We had multiple projects running at the same time, and as a result, some just never finished or were abandoned due to other priorities
2. The Sales Team were not happy that we could not provide them with better estimates of when features would launch
3. There was a lack of Engineering input since there were maybe projects starting at various times
4. This still felt like a Waterfall approach, when the PM would do requirements gathering (research), then pass it on to Design, then off to Engineering.

 

v3 – Introduce the Discovery process

With the problems mentioned in the last section, and with the timely attending of Marty Cagan’s How to Build Products Customers Love Workshop, we as a Product Managment organization decided to introduce the Discovery process and commit to it.

In a nutshell, this is what the process looked like:

We would work on any new projects in a timeboxed two-week sprint, with the goal that the end of the sprint we would know whether this was a problem worth solving and what was the right solution to build. This process required the Product Manager and Designer to work in close collaboration with each other and constantly talk to users to learn more about the problem and iterate on prototypes with them while keeping an engineer in the loop for their feedback.

Since we wanted to invest heavily in one problem for each of these sprints, we had to limit the number of projects we could work on at any given time, and that meant usually have only one project in flight at any given time.

This formal Discovery process brought us a number of benefits:

1. The whole product team was always on the same page. The team knew what the problem was, the expected outcome and the current progress at any given moment.
2. Since this process was more formal and had a certain cadence, the rest of the company knew the exact times they could get updates on our progress and provide input.
3. We were now able to give the Sales team better estimates of when features could go live given that we knew how long the Discovery process would be and when the feature would hit the Delivery team.

Although Discovery brought us some welcomed benefits, there were some issues:

1. There were still multiple projects in flight at the same time, or sprints were going over the 2-week mark.
2. It always felt like madness every sprint as we were trying to do too much in a short amount of time: we had to learn what the problem was and find a solution while also juggling meetings and other small features/enhancements that didn’t require this process

v3.1 – Separate Problem Discovery from Solution Discovery

In the regular Discovery sprint, we were trying to do two distinct tasks:

1. Understand the problem (Problem Discovery)
2. Solve the problem (Solution Discovery)

Problem Discovery ended up taking the majority of the sprint, which often left us less time to iterate on the solution. The reason Problem Discovery sometimes took too long was because it took a while to schedule customer interviews, and once we scheduled them, they were often midway into the sprint, which meant we had worked on a problem without sufficient research, not good.

To help reduce this “waste”, I am proposing separating Problem Discovery from the same sprint we perform Solution Discovery in.

Problem Discovery would be a 1-week sprint that the Product Manager would undertake every week with the following “deliverables” expected at the end of each sprint:

1. Understanding of what the problem is and the customer’s POV
2. A list of customers who have the problem and care about the problem so much they will commit their time to helping us solve it in the Solution Discovery sprint (Reference customers)
3. A list of outcomes the solution should deliver upon (initial scope)

With these items in hand, when the time is right (this problem is now the most impactful problem for us to solve right now), we can then swiftly move into Solution Discovery and accelerate through that sprint.

Here’s what that would look like:

 

It may even turn out that we do not need two weeks for the Solution Discovery sprint but can complete everything in one week!

Now I do realize that this seems to bring us back to Waterfall, and I know nobody likes Waterfall. However, the key difference here is that we are always making the decision at each stage whether we should continue investing our time and resources into this problem, instead of just blindly going through the motions.

 

 

This is definitely not the final process; I am constantly learning about my processes and evolving them so look forward to an update to this process once I have one to share!

 

Looking to learn more about the “right” Discovery process? Check out Teressa Torres’ timely post on Modern Discovery.