Taking over a misguided product

The reality

When I joined Duetto in February of 2017 I was presented with ScoreBoard, a forecasting and reporting application, in its early stages of release. The engineers were frustrated with limited direction, the sales team was not sure how to sell the product, the marketing message was unclear, and the customer feedback was that it was not ready. Things were not looking good. It was clear to me that I needed to reverse engineer this product. Typically before you start writing a line of code or putting together a prototype, you identify what problems you are trying to solve and why they are worth solving. Even though this product was already built I knew I needed to start from the beginning, not only to get context but to understand where things may have gone wrong.

Identify what problem(s) the product is solving

I started off by sending a survey to all existing users. I used a tool called TypeForm (it's free and awesome; I highly recommend it) to validate assumptions the previous Product Manager had shared with me and collect quantitative feedback. I received over 140 responses in 30 days that helped me identify and prioritize the pain points our users were facing. They included issues like:

  • Data living in disparate systems that required manual extraction and manipulation each time the user wanted to build a report

  • Using excel as the primary reporting tool; relying heavily on formulas that were prone to human error

  • Data became outdated by the time it reached the right people

  • Emailing reports was killing collaboration

  • Users were spending more time manipulating data than actually analyzing it

The list went on... Once I had identified the primary problems our ScoreBoard solution was focused on solving, I was able to put together clear messaging for the sales and marketing team to help them be more targeted describing the products value proposition to prospects and customers.

Define what problems the product faces

Next, my attention was focused on identifying the issues the product was currently facing. Why was the business telling me the product was not successful? Was it because we were having trouble up-selling the product to existing customers, expanding the user base to new customers, increasing revenue per user or number of paying users, or increasing user engagement? To answer this question I needed to do a number of different tasks. First, I asked for access to every closed-loss deal we had record of that related to ScoreBoard. I wanted to know why prospects walked away. Second, I implemented a tool called Pendo that tracks client side interactions so we could understand what our current users were actually doing in the product (more on this in another project). Third, I went through a market sizing analysis to understand how big the potential opportunity was for this product. I wanted to be certain we had a big enough TAM to go after.

go or no-go?

Once I finally had all the pieces of the puzzle I had to make the decision of whether or not we should continue to put time, money, and resources into this product or drop it all together. Sometimes tough decisions like this need to be made. I've seen many companies drag along products that ultimately were a drain on their bottom line (think Window's Vista). Luckily, all signs pointed to moving forward, but with a focused direction and clearly defined goals.

Prioritize. prioritize. prioritize.

As I dug deeper and deeper into the product backlog I found that there was very little organization to the order in which features were being added. As a Product Manager, prioritizing requests among bugs and ongoing projects is by far the most challenging task we have to perform. It's not easy pulling a story from a sprint that you love and have designed to perfection, but ultimately it's not about what we want because at the end of the day we are NOT the user. No matter how hard we try to convince ourselves that we are not biased, we are. To hold myself accountable I like to use a scoring matrix to validate my hypotheses and determine which projects get priority. I assign strategic business drivers to each project. The strategic drivers are broken down into categories (subject to change based on the product):

  • Revenue Driven - Based on the amount of revenue per year that we expect to collect as a result of this effort.

  • Innovation - Projects that are creating differentiation between us and the competition.

  • Decrease Cost - Efforts that address tech debt, support process automation, and support tools for internal teams.

  • Customer Enablement - Addressing existing customers, increasing value and happiness with new features/improvements; reduce churn

  • Trust - Includes efforts that have a direct impact on improving data quality/accuracy; performance reliability

  • Contractual - Projects that must be completed as part of a written and signed agreement with a customer.

Each category is assigned a point value weighted based on the business goals.

Get to work

Finally, it's time to start getting projects in motion. After 6 months of iterating, improving, and cutting scope I was able to re-launch ScoreBoard with great success. I created product marketing videos, conducted a thorough sales re-training session for our global team (complete with battle cards and rebuttals to common objections), and retrained our customer success team on how to roll out and service our new customers. In just 1 year, ScoreBoard generated $2.7m in ARR and is now considered one of our flagship products.