Why You Need a Product Manager as Part of Your Go-To Market Strategy

Hackathons have a lot of redeeming qualities (see previous post, no TL;DR here), yet there is a reason so many of the products and features built during these events never evolve.  Involving a product manager in the design and delivery of your products will increase the likelihood they will become a massive hit.There are some things that product managers simply do better than technical hackathon participants, many of which come from their ability to think broadly about a market need, define products that address that need, and then ensure product-market fit throughout its lifecycle. Some may argue that product managers are good at stifling true innovation and are too interested in creating knock-offs of other successful products and services. This is a far too limited outlook.As Victor Lombardi writes in Why We Fail, “If we only test bottle openers, we may never realize customers prefer screw-top bottles.” Great product managers know how to assess a market, understand trends, and build products focused on where the market is going, not where it has been. But there’s a lot more to it than that, there’s a handful of other skills that product managers possess which can be used to separate the products they work on from those that spring forth from hackathons. Many of these skills share a common trait: thinking about the future. Product managers want to ensure their products have a long and prosperous life, far from the one-and-done of a hackathon.

11 Things Product Managers Do to Launch Successful Products

Or, the (not so) secret blend of 11 herbs and spices (ok...skills) that product managers know that makes them a valuable asset in every product’s launch strategy:

Proper Validation: You Call That an MVP?!

Do not confuse what gets delivered at the end of a hackathon with an MVP. Often, a hackathon’s final product is closer to a working prototype. A legitimate MVP needs to have both a problem statement and hypothesis baked in, should be aligned with KPIs, and must be set up as a learning experiment. It’s rare for a hackathon team to have the luxury of enough time and resources to build out a fully-formed MVP. Prototype ≠ MVP. Stripped down functionality ≠ MVP, either.Lesson for PMs: A good product manager can use the output of a hackathon as the basis for an MVP, but an effective MVP requires a thoughtful approach, careful consideration of which hypothesis to test, and structured analytics to be able to assess the results.

Iterative Development: Version 2 (and 3 and 4 and…)

For all the things hackathons do well, they rarely result in a “Version 2” of whatever was being built. Many of the ideas and prototypes that emerge from a hackathon never evolve once the hackathon is over, they never mature, and they never find a group of people who adopt the prototype and nurture it into a real business. The most likely endgame for something developed at a hackathon? Abandonware.Product Managers know how to learn from early versions of a product and build upon its successes. They know how to nurture it, and grow it into a fully-functional product.Lesson for PMs: The work of building a product is never done, and launching a product is a process that runs on a continuum. Each version should be an improvement over the last based on what you’ve learned and what the market has told you. Great product managers make products that get used, not abandoned; this means that they continuously look for ways to improve, even if versions 1-5 are “good enough.”

Avoiding Technical Debt: Maintenance

Has the product or feature been designed in such a way that it can be easily maintained, updated and upgraded? Is there a roadmap of enhancements? Are these taken into account as the product or feature is developed? These considerations are the difference between putting together your mise-en-place and cooking an eight-course meal. They’re the difference between throwing something together at a hackathon so it just works well enough for a 90 second live demo versus thinking about the long term plan for ensuring near-continuous uptime.Lesson for PMs: The problem with the quick and dirty build mentality is that long after quick is forgotten, dirty remains. Product Managers are the stewards of their products’ futures, and they know this well. They’re responsible for building products for the long haul, and so they should make sure things are done in such a way that they can be easily managed and maintained. Having this kind of oversight early on in the development process can make or break a product’s future.

Knowing Thy Customer

Product managers must know and understand their customers. Some PMs know their customers because they, themselves are their target audience, but great PMs can empathize with and intimately understand their customers even if they are nothing like them. Your palate is different from your friends’; a great chef understands this and will adjust a dish’s seasoning based on your likes and dislikes. Storytime! I once ate at a small Japanese restaurant in Tokyo where the chef was cooking in the middle of the tatami-matted dining room. As each course was served, he observed what and how each person ate, then adjusted subsequent dishes based on their observed likes and dislikes. After a progression of increasingly sophisticated courses, the dish that was too much of a challenge for me was the live octopus. I simply could not get past the idea of eating a still wriggling sea creature. So he made my next course more tame. It was a truly awesome experience precisely because he learned by watching, then adjusted the next course accordingly.The corollary, of course, is that if you are not your target market, your opinions really do not matter. They’re just your opinions. You need to have the self-awareness to realize when you are imposing your own tastes and biases. If my Japanese chef had been cooking what he wanted, regardless of my preferences, that meal would have been memorable for all the wrong reasons.As Jon Kolko posits, “There are two fundamental qualities that make up a product – product/market fit, and behavioural insight.” Product Managers need to understand the former, and serve as a proxy for the customer in order to figure out the latter.Too often, the teams creating applications at hackathons are building products, apps, tools and features which they themselves would want to use. They’re living the old adage, “Write what you know.” But in so doing, they are missing large swaths of the world who are different from them. There’s gold in the swaths, and product managers are the miners, you need them to gather what your audience needs and wants.Lesson for PMs: Know your audience, and remember, your audience is likely not just like you. Cater to what your audience needs and wants.

Designing for Scale

Sure, you created a prototype in a weekend at a hackathon, but will it stand up to the hard wear and tear real users will put it through? Of course not, that would be an insane achievement to make within such a quick burst of development time. The real question is if you’d had more time, would you have known how to make it stand up to real-life use? Would you know how to scale?Product managers know their audience well enough to know and understand just how robust a product or feature needs to be before it can be released for general use. They’ll often take into account things like system load, accessibility, security, performance, local and federal regulations, localization, internationalization, and much more. They’ll also have a plan in mind for growth; scaling the product’s power alongside its userbase.While the goal of early versions of the application or product may be to just gather enough feedback to figure out where invest more time and effort (validate the idea), at some point the product needs to grow up and become commercialized. Product managers are our heroes  when it comes to this stage, they’re able to commercialize a product in a single, uh, meeting because they design for adaptability early on and ensure the finished product will be robust enough to stand the rigors of real users, at scale. (It's Super Product Manager Person! Right. Least interesting Marvel super hero. Ever.)Lesson for PMs: Early on, design for adaptability. Once you know enough, make sure the product will be robust enough to stand the rigors of real users, at scale.

Finding Product / Market Fit

Now, we’re getting to the meat of the meal. During hackathons, we make a lot of assumptions about the market and whether a particular product will be a match. Product managers are market experts; they understand their customers and understand the market problems they are trying to solve. One way to validate product-market fit is by using a Lean Business Canvas to assess suitability. These are the key areas to address when dissecting product / market fit and assessing a business model, adapted from Ash Maurya’s model:

Problem: Your top 1-3 problems

Existing Alternatives: How are these problems solved today

Customer Segments: Your target customers and users‍

Early Adopters: Characteristics of your ideal customers

Unique Value Proposition: Single, clear compelling message that turns an unaware visitor into an interested prospect

Solution: Outline a possible solution for each problem

Channels: Your path to customers

Revenue Streams: Your sources of revenue

Cost Structure: Your fixed and variable costs

Key Metrics: Key numbers that tell you how your business (or product) is doing

Unfair Advantage: Something that cannot be easily copied or bought

Lesson for PMs: Product Managers know how to create products and features which are designed to solve a particular problem or fill a specific need for a particular audience, and they consider how it will work in concert with the business model, which is critical to a product’s success from a revenue standpoint.

‍

Actually Getting a Product to Market

Hackathons are about coming up with possible solutions, creating a working version of something, then pitching it in a short demo. As much as we’d like to believe “if you build it they will come,” that’s just not the case. Hackathons are not (usually) focused on how you bring a product to market. All (ok, many) hyper-successful products and companies have a cogent plan for creating awareness of their offering and getting the offering in front of the right people, they have a go-to market strategy and launch plan. Part of the Lean Canvas exercise described above is to identify your customer segments and then to choose which channels to use to get in front of the different segments.Lesson for PMs: It’s not enough just to have a great product. Think carefully and plan (alongside marketing) how to take it to market, and develop a concerted, choreographed roll-out to engage your target segment(s) early and often. This is the hard, gritty work of launching a product.

Growing the Userbase and Getting Traction

Usually, the main focus of a hackathon is to build something, anything and present a working version of an idea. Knowing how to launch a product and build a loyal, consistent base of users is the key to ongoing success, though. As I mentioned above, product managers understand how to launch a product, and they also understand how to attract and retain users. Often, they go at it armed with an arsenal of clever techniques:

• Baking into the product itself a mechanism for self-promotion. Blue Apron, for example, allows customers who have had 3 or more meals delivered to gift a free week’s worth of meals to a friend. Ingenious. It also works as a lead qualification tool.
• Targeted marketing
• Viral Marketing
• Analytics to assess which customers are responding to and using the product
• In some cases, your product or feature may be a good match for the burgeoning approach of growth hacking.

Lesson for PMs: Building a great product may be satisfying, but it is only the beginning. Ultimately, you want people to use your product and product managers know how to keep an eye on how and where the product is gaining traction. They also are able to work closely with their counterparts in sales and marketing (if they have them) and devise strategies for continuing to move the product forward.

Related: You Built it...But No one Came, Now What? >>

Learning from Actual Product Usage and Adapting

The hackathon format is not conducive to creating a continuous feedback loop since it is such a short-burn project. While you may get feedback on your v1 release, there is rarely the time or incentive to continue iterating (unless you’re among the winners, of course). Product managers are masters of macro- and micro-feedback.On the macro level, they understand how the product is being used, by whom, how often, and in which context(s). Is it meeting the needs of users?  Are there structural changes you can make to better meet their needs? Product managers know how to answer these questions and gather feedback through analytics, in-app feedback mechanisms, through surveys, focus groups... there are some fantastic tools available to help you take the pulse of your userbase. (Ahem...)On the micro level, they’ll focus on optimizing smaller interactions and experiences, the types of events and moments of delight that make customers want to keep using a product. For example, as Martin Eriksson writes about Tom Chi’s approach to getting feedback, quickly:“Loop length is the amount of time between asserting a new conjecture and observing the actuals from that conjecture. Most of us have a loop length measured in years or months. Even if you’re releasing every day through continuous releases, but not learning anything from actuals from customers, that loop is open and it needs to be closed.”“Tom’s teams work with loop lengths measured in days. They create a cadence by building in non-negotiable customer feedback time twice a week, where they test whatever they have built so far in order to capture the actuals and key learnings. They will even have the development team on speaker phone during the testing to get the loop length on small usability issues down to 15 minutes. In addition to these immediate optimisation lessons, they’re looking for “eyes light up” moments where the customer responds to your product.”Lesson for PMs: Product managers have the benefit of time to set up continuous feedback loops and in turn have the opportunity to deeply understand how people are using a product and how they can be improved. (The products, not the people.)

Pricing for Profitability (or Other Key Objectives)

Hackathons are not designed to vet out whether an idea can be self-sustaining. Some hackathon participants scoff at the idea of creating a profitable product, others are enamored with creating something cool, innovative, interesting, slick; whether it can ever make money is much lower down on their list of priorities. In some cases, a hackathon project may mature and become a business, in others, it will remain a feature or shrivel on the (metaphorical) vine.However, once a product has a product manager, there is some expectation that this thing, this feature or product or whatever, will contribute to the bottom line. That bottom line may or may not be monetary. Some examples of bottom lines might be:

• Price Point
• Promotion / Loss Leader
• Lead Generation Tool
• Lead Qualification Tool
• User Registration / Onboarding
• Surprise and Delight

Ultimately, the product manager has a responsibility to measure the Return on Investment (ROI)  of their particular product or feature, even if that return falls into the often hard to quantify “Surprise & Delight” category.Lesson for PMs: You are in charge of your product. As such, you are responsible for defining and measuring both the R and the I to figure out the ROI.

Innovation: Failure is Not an Option

Hackathons celebrate failure. Teams participating in a hackathon are expected to push both themselves and the limits of innovation, and with that hard push comes a high failure rate. The role of a product manager is to increase the success rate of new products and features, while also retaining innovation and creativity.Lesson for PMs: Failure on a huge scale is not an option, yet if you’re not failing sometimes, you’re likely not challenging the status quo hard enough. But, if every project you are involved with ends in disaster, that’s not a recipe for success, either. Product managers (often) have the maturity and insight required to understand just how hard to push.

The TL;DR

Quick and dirty may be the best way to build a prototype at a hackathon, but product managers know that it’s the opposite of quick and dirty (thoughtful and structured) which leads to a product’s sustained success. Product Managers are masters at assessing markets and understanding what types of products and features will appeal to different customer segments. Ultimately, Product Managers are responsible for ensuring their products are successful. Failure on a huge scale is just not an option.