Building the right product.

This post shares some of my experiences with outbound product management. I delve into learning moments from past epic failures, as well as best practices that have resulted in success.

While this post references some inbound product management anecdotes, its focus is on the outbound aspect. I will share inbound product management reflections at great length in a separate post.

Outbound vs. Inbound Product Management

In its simplest form, product management can be divided into two parts: outbound and inbound.

• Outbound product management focuses on tasks outside of the company such as learning about problems and pains the market and customers are experiencing. The goal of outbound product management is to build the right product.
• Inbound product management focuses on tasks done within a company such as working with the various teams to define, design, and build the product, and getting it ready for the market. The goal of inbound product management is to build the product right.

Imagine a Scenario…

Imagine you’ve built an awesome ice making machine. Your ice machine could convert 500 pounds of water into 500 pounds of ice in just one minute. It could run on rechargeable batteries. The machine only weighs 10 pounds. It will last as long as 20 years. And get this, it only costs $200!

You meet with every single person living in Antarctica to sell them the machine. Nobody ever buys it. You go out of business.

This scenario is exaggerated to the extreme, but it is meant to illustrate the importance of building the right product.

People don’t buy products or services. They buy solutions to their problems.

In order to build the right product, a product manager needs to understand what kinds of problems their target customers have. It’s incredibly easy to fall in love with your own product. It’s natural to grow an emotional attachment from seeing it transform and evolve over time. But if you built the world’s best ice maker for people living in Antarctica, your business is in a world of hurt.

To borrow a quote from my mentor at ThinkHR, “Fall in love with the problem, not with the solution… You need to understand the problem first, so that you could deliver the right solution.”

This sounds obvious, right? Identify a problem, then build a solution that solves that problem. People buy it. The company (and hopefully you) get rich in the meantime. Easy, right?

Unfortunately, we are all are susceptible to human error, emotions, and assumptions. Allow me to share some real costs of building the wrong product.

The real costs of building the wrong product

Example 1: CRM at Faria Systems

During my time at Faria Systems, the company built its own customer relationship manager (CRM). Some context: a CRM is a tool that allows a business to manage their relationships with customers and potential customers. For instance, it allows you to view past correspondence with customers; to generate new invoices or view outstanding invoices; to see what additional products can be upsold to customers.

The CRM was used internally by the sales and marketing teams. After observing its internal usage for a couple months, the CEO made a push to sell the CRM to other software companies. The assumption was that markets in Asia, Australia, and New Zealand needed this particular solution because it was integrated with Xero, a New Zealand-based accounting software company. We asserted that our solution would provide seamless integration between CRM and enterprise resource planning (ERP) to help software companies scale on top of Xero.

R&D efforts alone cost $300,000 to build the CRM. In addition, purchasing the web domain cost $3,000. Marketing collateral such as data sheets and conference posters were made. Engineers created a demo environment staged with realistic looking data. Staff were trained on how to sell, support, and market the product. The go-to-market strategy was ready, despite never validating the product with a single potential customer.

Fast forward a few months, ZERO licenses were sold. The CRM market is already saturated, commoditized, and dominated by Salesforce and a few smaller key players. Nobody found any value from our “seamless integration with Xero.”

We built the wrong product, and it was an expensive six-figure lesson. Luckily, the company was profitable and could afford the loss.

Example 2: Shoe App at Shoelives Ltd.

In 2016-17, an international Chairman/CEO hired me as a part-time management consultant. His company operated in the wholesale shoe business, with most of the revenue coming from retail. He wanted to diversify beyond retail and compete with e-commerce giants.

I was tasked with using my knowledge of software and product management to form a new software division. The goal was to create an app platform for the Chinese market that enabled (i) designers to upload shoe designs, (ii) regular shoppers to buy shoes based on the designs they viewed, and (iii) factories to fulfill these orders. In the end, the consumer would pay for shoes they liked, factories made money, and designers would also get a cut by supplying the design.

The company owned the entire vertical market from shoe design and prototyping, to manufacturing in factories, to distribution, and finally to marketing and sales. In addition to hiring the software team and investing in the software infrastructure, it would supply the initial designs and front the manufacturing costs. The goal was to gain enough traction to attract external designers and manufactures to come onto the platform. In turn, we’d take a cut off the factories’ and designers’ earnings.

I tried to do outbound product management due diligence. I interviewed the Chairman on multiple occasions to understand what kind of problem we were trying to solve. I flew to Shenzhen to meet the two business consultants who spearheaded the initiative with the Chairman. I did not interview potential customers. I did not conduct market research. These oversights were due to three main factors: I had (i) limited understanding of the Chinese market, (ii) limited knowledge of the shoe business, and (iii) limited time due to being fully employed at Soloshot.

Nevertheless, I was reassured that this idea would succeed. A new business entity was formed, and onward we marched. Over the next few months, I taught the Chairman and business consultants about the software world, built out a software team, and defined the first version of the product.

The entire experience was immensely gratifying. We spent days in meeting rooms going over the software development life cycle (SDLC), building out the team structure, proposing timelines and budgets, and defining the product.

I hired a Chinese/English interpreter of my choosing and brought her with me to China to interview and hire a software architect, technical project manager, and several software engineers. I also hired a Taiwanese UI/UX Designer who reported directly to me. In parallel with building the team, I transformed the idea into functional requirements for the designer to create the information architecture, wireframes, and eventually the prototype. When development took off, I served as a consultant to the Chairman and software team.

6 months later, the product shipped its first version in China! …and the fun ended.

The team reported numbers on app views and app downloads. They reported the number of features being shipped, and at what pace. And on the future roadmap that refined the business strategy. These vanity metrics didn’t matter. None of it mattered, because app usage/engagement was low, and the number of purchased shoes were even lower. The company was just not making money.

I wish there was a happy ending to this story, but there isn’t. 18 months after my first meeting with the Chairman, the limited company was shut down. The team of 20 people were laid off, many whom I liked. The company wrote off a massive loss from its sunk cost. Quite simply, we built the wrong product.

Figure out what the problems are to validate (or invalidate) your idea

Part of being a good product manager is to validate idea(s) with these customers and the market. If there’s no problem worth solving, then there’s no point investing in a solution that nobody will want.

The CRM and the Shoe App products were solving a problem that didn’t really exist. We put our desire for a solution before the needs of customers and never identified any real migraine-level problems worth solving.

According to Diana Kander in All In Startup, “Initial ideas are filled with a number of assumptions, many of which, if guessed incorrectly, could change the entire trajectory of a business.“

Having certain business assumptions does not mean you should be paralyzed with fear and never take any action. It does not mean that you should acquire perfect information (which is impossible) before taking any action. You can take immediate action by identifying who your customers and their problems are. Talk to them, and not from the perspective of selling. Approach these user interviews from a place of learning and empathizing with their problems. Research the market, and see what other companies are or aren’t doing. Doing both will give you a much more powerful starting position to build the right product.

If you’ve interviewed customers, looked at the market, and have determined that there is no problem worth solving, that is okay! Good outbound product management oftentimes means NOT building a product, else risk it becoming useless and moot.

Example 1: killing a product idea at ThinkHR

Some context: ThinkHR provides HR and business leaders the tools and guidance they need to prepare for and manage day-to-day people risk.

At a senior leadership meeting at ThinkHR, some spent was spent brainstorming product ideas to pursue. One of the ideas was a “Compensation Product.”

I was given ownership of this product idea. Leadership meetings are very high level and conceptual, and thus I had few details to work with. I had to first figure out what a Compensation Product was. I spent a few days learning about the market, looking up existing companies in the compensation space, looking at our customers’ past requests, and at company data. I documented all my findings.

It was difficult coming up with a viable solution that was aligned with our company vision. To present some options, I collaborated with some colleagues who held subject matter expertise in the HR space to come up with a potential solution that we could build.

Eventually, I presented the proposal to the senior leadership team. The CEO asked me for honest feedback. “Thumbs up to proceed, or thumbs down to kill?” With hesitation, I gave a thumbs down. My resolve and the data was enough to convince the the team to squash the idea then and there. It wasn’t the right product to build. The only cost the company incurred was my time, which is literally peanuts compared to investing in R&D and go-to-market efforts.

Example 2: proceeding with an idea at ThinkHR

Another idea thrown around at ThinkHR was something that I unfortunately cannot share that much details about. Why? Because we’ve just released the first version a month ago and are in the middle of learning, iterating, and fully productizing it!

The process was the same. An idea was first thrown around, and I took ownership of it. I looked at the market and determined that it was worth pursuing. But instead of going all-in without confirming my assumptions, which may have resulted in a very costly mistake, my approach was through a series of small, inexpensive bets.

• Spent 1.5 days writing high-level functional requirements, creating an information architecture, and designing a bunch of wireframes using Omnigraffle.
• Spent 0.5 days creating a prototype from those wireframes using InVision.
• Spent 1 day conducting interviews using the prototype as an illustration for storytelling, and documenting all the feedback.
• Spent 15 minutes presenting my findings with my boss to the CEO, who granted us a small budget to create a first version to deploy to users.
• Spent 2 weeks building the first version with the engineering team, including analytics to track key metrics.
• Spent 2 hours doing internal demos and training various teams on the product.

The first day after shipping the product, the Customer Support team received unsolicited feedback from a customer, exclaiming that the product was amazing. Later on, the sales provided additional feedback that, during a demo of our entire product suite, much attention was centered around this particular product, with the prospects desiring more!

The only way to determine whether your guesses are right is to test them in the real world. And we did just that through a series of small bets. Don’t worry about making the product perfect from the beginning. The goal is to validate it with the market. To quote Reid Hoffman, “If you are not embarrassed by the first version of your product, you’ve launched too late.”

Don’t go all-in without confirming your assumptions through smaller bets

The above header is another quote from Diana Kander.

By testing business assumptions with the market and target customers, a company is bound to increase its probability of building the right product. This practice has helped me create profitable products and experience success at companies. It’s also helped me kill off a few product ideas. Although a small part of my wonders whether the ideas would have succeeded, I much prefer that sentiment over a huge failed investment.

The Shoelives Ltd. app is still on my phone. I keep it partially for sentimental value to remind me of some fun times, but also to remind me of the costs of building the wrong product.

Thanks for reading! In a future post, I will go into details about inbound product management.