How to Win-Win-Win in Product Partnerships (Hint: Users always first)

Product managers are the conductors of the SaaS orchestra.

It is our job to pull together teams that speak different languages, have different strengths and different focus into one cohesive sound. Hopefully this is music to our customer’s ears, they love the product your team built and become advocates of your brand.

But how do you do that?

By listening … to the user.

This isn’t easy. As the noise of the investors, the sales team, the technical team, the new recruit starts reverberating through the office, it’s easy to lose site of the end user.

It is the Product Managers job to be the voice of the user in every conversation, but at the end of the day it’s still business. So you aren’t just the voice, you are also the negotiator, the problem solver and have an obligation to the bottom line.

The tool of the every conductor? The baton.

The Product Manager’s baton – the Product Roadmap.

In it’s most basic form the Product Roadmap outlines the development of the application over a specific timeline. Generally, the further in the future the more vague it becomes. It is meant to be a general guideline that you can share amongst teams so that everyone knows what symphony they are in and when to hit their notes.

Yet it is also a negotiation. People aren’t just numbers to be moved around on the roadmap of a product. There is emotions and motivations that need to be understood if you are going to be successful in getting your Product out the door.

I worked as a Product Manager & Owner on two different SaaS that were both acquired by a parent company. I had to work directly with the founders and development teams to integrate them into the main company.

There were constraints on the product roadmap because of the contractual obligations for the exit of the founder of the new software acquisition. Although I was out of the business negotiations, it was my role to create a product roadmap that would satisfy both parties and be a good product-market fit for our users.

This meant I needed to get a handle on the following

  1. Who is our customer for this new software? What do they want, what do they need, and what is the biggest pain-point for their business.
  2. What does the competitive landscape look like? How do we fit into the market, what are our strengths and weaknesses and how do we plan for them?
  3. What are the business goals of the acquired and the parent company?

In order to answer these questions and balance the interests of all three, I did research and then worked on a road mapping exercise with the founder of the acquired company.

(I won’t go into depth on the competitive research and customer personas in this post but if you are looking for frameworks, I suggest Roman Pichler’s book Strategize to get you started.)

Start with the USERS Return on Investment

We distilled the information from multiple sources (customer service ticket deep dive, user interviews, competitor reviews & brain-dump from founder and lead developer) and used a Trello Board to organize the features according to impact.

We then separated the Trello Board into High, Medium & Low ROI categories for the USER.

  1. High ROI – New features that fixed an immediate pain for our users.
    • In our case a feature that help our users understand and target their customers on Amazon better or make tax time for their ecommerce business easier
  2. Medium ROI – features and developments that would make the application easier to use
    • This would encompass making the app more mobile friendly or provide modest improvements on existing features
  3. Low ROI – features that only impacted a small portion of users or were purely aesthetic nice-to-haves

User ROI

Tl;DR We brain dumped all feature developments and then organized them based on the biggest Return on Investment (ROI) for the end-user. This was done to keep market-product fit as the primary driver for product development.

Get to the WHY

After I really had a solid understanding of the users, it was time to look at not only the business goals of both parties, but understand the motivations behind why these goals were prioritized.

The acquired company was looking for user growth – he wanted more users for the existing markets, high adoption rates their software and new feature development.

Why was this important? This was for two primary reasons, first the tool was still basic and lagging behind a few key competitors. A more robust feature offering would bring us to feature parity. The second reason was that a high adoption rate would make the software more valuable when it came to the final pay-out from the parent company.

The parent company was looking for marketshare – they wanted to scale the acquired software to service all of the international markets it already had a presence in.

Users (1)

Why was this important? There was an upcoming round of capital that was being raised and the investors were non-US based and looking for global investment opportunities. Our director strategy was around “winning minds” in our existing markets as an “All-In-One tool” and there were few offerings in the EU marketplace for our newly acquired Financial Dashboard tool.

TL;DR At the surface both the acquired and parent company were looking for growth via a bigger user base. The differences is that the acquired company was looking to grow its users in the US by building more robust features so they could negotiate a higher exit package, where the parent company wanted to take the existing offering to the Europe to have first to market advantages and satisfy investors.

Buy-In from everyone

From there we needed to develop a balanced roadmap that was supported by all parties. This involved a lot of negotiation and discussion with all the primary stakeholders – owner, founder, development team, quality assurance and project manager.

We were able to break the feature development into the following categories:

  1. “Baseline” – these were technical debt and scalability tasks that needed to happen to the infrastructure immediately in order to scale the platform to handle more users.
  2. “Big & Hairy” – these were features that involved some heavy lifting from the development team in order to fulfill the contractual requirements of the acquisition, namely support for European markets that would help us acquire and bring new users onto the platform.
  3. “High User ROI” – these were big feature developments that would make the platform more sticky and help us retain the users we acquired
  4. “Easy Wins” – these were easy wins that we could implement quickly that would make a better user experience and help short term adoption rates and delight our existing customers.

After mapping out dependencies, resources and constraints with the technical teams and CTO we were able to build an outline of the roadmap that satisfied all parties.

What did that look like?

As we were scaling our development team with the platform, our lead developer became a scarce resources. With help from the Project Manager we were able to come up with a creative solution to find a common ground between old/new users and founder/parent company goals.

We would use the lead developer to tackle the “Baseline” and “Big & Hairy” problems, taking opportunities along the way to cross train and guide the new developers. Whilst getting the new developers to use the “Easy Wins” and  “High-Medium User ROI” tasks to learn more about the platform incrementally and move both timelines along.