My product management toolkit (39): go-to-market checklist

 

Thinking about how to best launch a product or feature to market can easily become an afterthought. I’ve certainly made the mistake of being so immersed in the execution of an idea that I forgot to think about how to best take a product to market. It doesn’t matter whether your product or feature is consumer facing or aimed at internal customers, I recommend considering the following as part of your go-to-market checklist:

Pre-Launch

  • Positioning statement – Write a positioning statement which explains succinctly who the product is for, what the product does and why it’s different from other products out there.
  • Internal announcement – Do an internal announcement of some sorts – e.g. at a staff meeting or via email – to let people know that a new product or feature is coming. This helps to build momentum and excitement as well as get valuable internal feedback in the run-up to launch.
  • Success criteria – Agree on the measures of success for your product, both quantitative and qualitative. What does ‘good’ look like post-launch and why? What kind of customer feedback are you hoping to receive once your product is live, which metrics are you expecting to be impacted positively? How do you manage ‘bad’ customer feedback? Upfront alignment on success or failure will also mean that you’ll be able to iterate quickly on your product or messaging if things aren’t heading in the right direction.
  • Training and demos – When launching a new product or feature, it’s important that people across the business have seen the product in action and have been trained on how to use it. Think for example about the people in customer support who might get inundated with customer questions once the product has been launched.
  • Launch date – Set a date and time for the launch and communicate to both people within and outside of your company. Your colleagues and a select group of customers can both provide you with valuable feedback prior to launch and spread the word. Also, make sure that your launch date doesn’t coincide with national holidays, other planned launches – by your company or a competitor – etc. as you don’t want the announcement of your new product to snow under.
  • Promotional content and FAQs – This covers all content and materials that will help explain the product, its benefits, who / what it’s for, and help (target) customers of the product. Drafting FAQs and sharing them internally and a select group of potential customers first, is a great way to make sure you’ve pre-empted any questions or concerns your target audience might have.
  • Media planning – As Pawel Lubiarz explains, launching a product without a media plan in place is a considerable risk. You’re only going to launch your product once, so you need to make the most of that occasion. Which digital and print media would you like to help message the launch of your product? Which journalists are likely to report on your product?
  • Press release – Draft a press release that captures the key aspects and benefits of your product and share with journalists and media outlets that you’ve identified (see my previous point).
  • Test. Test. Test – I know it sounds obvious but even if you think have tested your new product or feature, please make sure you test again in the run-up to a big launch. get people who aren’t as close to your product as you and your team to use the product, and look out for any glitches and gotchas.
  • Social media strategy – Create the launch announcement and content to be posted on relevant social channels, and think about appropriate content formats and frequency for the different channels that are relevant to your brand. The content you share on TikTok is likely to differ widely to what you put out via TechCrunch, for example.

Post-Launch

  • Launch evaluation – How did your product launch go? What did we learn? How we can iterate on our product and marketing our product, based on the initial numbers and customer feedback.
  • Reach out to customers – Customer learning doesn’t stop once the product or feature has been launched. Reach out to customers who have bought or used the product, people that left feedback or raised support questions. Consider creating new content to share now that the product is out in the market.

Main learning point: I’m sure that there’s a lot more items that could be added to my go-to-market checklist so please feel free to leave a comment or reach out with any suggestions of things to include!

Related links for further learning:

  1. https://www.aha.io/roadmapping/guide/release-management/what-is-a-good-product-launch-checklist
  2. https://tinuiti.com/blog/ecommerce/product-launch/
  3. https://blog.hubspot.com/marketing/product-launch-checklist
  4. https://moz.com/blog/product-launch-checklist
  5. https://backlinko.com/product-launch-checklist

 

 

Book Review: “Red Teaming” by Bryce Hoffman

Groupthink or complacency can be devastating when developing great products. Having someone who plays or is a devil’s advocate is often a welcome aspect of the product development process. So-called “red teams” take playing devil’s advocate to the next level; the mission of such teams is to force businesses and people to think differently. Red teams will push businesses to consider alternative points of view or contemplate worst case scenarios. Red teaming makes us aware of our assumptions and cognitive biases, and offers us a means of overcoming them. “Red Teaming” is the brilliant book by Bryce Hoffman in which he examines the origins of red teaming and offers an abundance of red teaming techniques.

 

 

 

Red teaming exercises are applied in a wide range of contexts:

  • Cybersecurity – Companies hiring specialised red teams to attack their technology and exploit security vulnerabilities. Going beyond standard penetration tests, red teams will act as aggressively and unrestricted as any hacker would.
  • Intelligence – Whether it’s NATO, the CIA or the Israeli army, they all have teams dedicated to doing “alternative analysis”, set up explicitly to challenge prevalent assumptions within intelligence bodies.
  • Business – When developing a business strategy, companies often consider a best case scenario, assuming that everything will go to plan. Red teaming exercises can help in laying bare any strategic gaps or flaws, helping companies scan the business environment for both threats and opportunities.

Whatever the context, red teaming is all about rigorous questioning and thinking unconventionally. Red teams consists of people who’ve proven to be contrarian thinkers. These are the three phases of a typical red teaming exercise:

  1. Using analytical tools to question the arguments and assumptions that too often go unquestioned during the regular planning process.
  2. Using imaginative techniques to figure out what could go wrong – and what could go right – with the plan, in order to expose hidden threats and missed opportunities.
  3. Applying contrarian thinking to challenge the plan and force the organisation to consider alternative perspectives.

Hoffman argues that adopting a red teaming mindset means that you’re not taking anything for granted, challenging everything and thinking the unthinkable. Red teaming is about looking at the future, and not getting burdened by the past. In the book, Hoffman also explain what red teaming is not:

  • A challenge to leadership – The red team’s role is to empower leaders and managers to make better decisions by providing them with a more objective analysis, a more comprehensive picture of the business environment, and alternative options to consider.
  • A creator of new plans – Hoffman stresses that red teams don’t make plans. In contrast, their purpose is to make existing plans better.
  • Always right (or has to be right) – Red teams don’t need to be right to be effective. They work more effectively in those environments where it’s ok to be wrong.

The question arises when it make sense to create a red team. Hoffman explains that although all red teaming starts out with a problem, not all problems require red teaming. David Snowden’s Cynefin framework is great tool to figure whether it’s worth doing a red teaming exercise:

 

 

Fig. 1 – David Snowden’s Cynefin framework – Taken from: https://www.researchgate.net/figure/The-four-contexts-of-the-Cynefin-framework-When-in-disorder-the-actual-context-is-not_fig2_283194976

 

If problems fall in the “complicated” or the “simple” quadrants of the Cynefin framework, they can be solved through a more straightforward, reductionist approach to problem solving. Problems that are “complex” or “chaotic” tend to be much more open ended and fluid, thus benefiting from a more radical problem solving approach. Ideally, red teaming should begin after a plan has been created but before it has been approved, while there’s still time to approve it.

Finally, Hoffman’s book contains a range of valuable techniques to consider as part of a red teaming exercise:

  • Problem Restatement – When faced with a challenge or problem, one of the best first steps in solving – even before you start thinking up possible solutions – is to examine and restate the problem.
  • Think-Write-Share – This technique is a way of ensuring that the red team begins with divergent thinking and moves to convergent thinking. The technique works like this: Start by asking team members to think about a problem or question, then write down their thoughts and share them with the group.
  • 1-2-4-All – 1-2-4-All enables you to engage all team members simultaneously – irrespective of team size – in generating questions, ideas, and suggestions.
  • Argument Dissection – Dissecting an argument involves asking a number of questions of any argument that is used to justify a particular course of action, or that is offered as an explanation for a problem.
  • Key Assumptions Check – Hoffman explains how in red teaming, it’s essential to differentiate between facts and assumptions. Facts are things that are objectively true right now. However, most plans fail because they rely on unstated or unexamined assumptions.

Main learning point: Red teams or red teaming exercises can be extremely valuable for businesses, whether you’re creating a strategy or developing a new product. Red teaming breaks through groupthink and inertia, and will offer important alternative perspectives to consider.

 

Related links for further learning:

  1. https://en.wikipedia.org/wiki/Red_team
  2. https://brycehoffman.com/books/red-teaming/
  3. http://web.archive.org/web/20130509055208/http://slashdot.org/topic/bi/symphony-of-self-destruction-strengthening-security-with-a-red-team/
  4. https://foreignpolicy.com/2015/10/30/inside-the-cia-red-cell-micah-zenko-red-team-intelligence/
  5. https://www.act.nato.int/images/stories/events/2011/cde/rr_ukdcdc.pdf
  6. https://www.act.nato.int/images/stories/media/capdev/capdev_03.pdf
  7. https://hbr.org/2007/11/a-leaders-framework-for-decision-making
  8. Morgan D. Jones – The Thinker’s Toolkit
  9. https://www.nasa.gov/sites/default/files/files/4-TWPS_Template.pdf
  10. http://www.liberatingstructures.com/1-1-2-4-all/

 

My product management toolkit (38): discovering opportunities and solutions

As product people we all know how enticing it can be to take an idea for a product or feature and simply run with it. The number of product teams I come across that will straight away test a specific idea without understanding the problem or opportunity it’s trying to address is plentiful. This observation is by no means intended as a criticism; I know first hand how easy it is to get excited by a specific idea and to go for it without contemplating any other ideas.

Teresa Torres – probably one of the best product discovery coaches I know – observes that “we don’t examine our ideas before investing in them” or “our solutions don’t connect to an opportunity or our desired outcome at all” (you can find Torres’ observations in her great article here). To solve these issues, Torres has come up with the “Opportunity Solution Tree” framework:

 

 

Taken from: Teresa Torres, Why This Opportunity Solution Tree is Changing the Way Product Teams Work, https://www.producttalk.org/2016/08/opportunity-solution-tree/

 

Torres argues that “good product discovery requires discovering opportunities as well as discovering solutions.” Product people are problem solvers most and foremost, and Torres encourages us to start with the problem first and I like the definition of what constitutes a problem by the late David H. Jonassen that she refers to:

 

“A problem is an unknown that results from any situation in which a person seeks to fulfil a need or accomplish a goal. However, problems are problems only when there is a “felt need” that motivates people to search for a solution in order to eliminate discrepancies.”

 

This problem definition by Jonassen made me reflect on what makes an “outcome” as defined in the excellent book by Joshua Seiden titled “Outcomes Over Output”:

 

“Outcomes are the changes in the customer, user, employee behaviour that lead to good things for your company, your organisation, or whomever is the focus of your work.”

 

Torres talks about how we often will retro fit an idea or solution to a desired outcome, thus failing to both fully understand the desired outcome and explore an appropriate number of potential solutions to that outcome:

 

 

Taken from: Teresa Torres, Why This Opportunity Solution Tree is Changing the Way Product Teams Work, https://www.producttalk.org/2016/08/opportunity-solution-tree/

 

Instead, Torres’ “Opportunity Solution Tree” encourages us to think about the desired outcome first, after which we can explore opportunities to achieve the desired outcome. We can then examine each opportunity and potential solution in more detail, cross-compare perceived value of each solution in a more objective and systemic manner:

Main learning point: A key takeaway from the Opportunity Solution Tree is to consider multiple opportunities and solutions. Whilst this may sound like no brainer, we’re often tempted to zoom in on or commit to a single opportunity or solution straight away, failing to consider its impact on the desired outcome.

 

 

 

 

 

 

Book review: “Outcomes Over Output” by Joshua Seiden

Over the years I’ve learned a lot from Josh Seiden, starting with “Lean UX” which he coauthored with Jeff Gothelf. Seiden recently published “Outcomes Over Output” a nifty little book (should take about 40 minutes to read), which – you guessed it – encourages it readers to move from “making stuff” to creating outcomes by changing customer behaviour. Seiden asserts that customer behaviour is the key metric for business success:

  1. What is an outcome? Seiden defines an outcome as “a change in human behaviour that drives business results.” He goes on to explain that outcomes have nothing to do with making ‘stuff’ – though they’re something created by making the right stuff. He explains that “outcomes are the changes in the customer, user, employee behaviour that lead to good things for your company, your organisation, or whomever is the focus of your work.”
  2. Delivering value early and often – Instead of big bang product releases, Seiden stresses the importance of creating specific, smaller customer behaviours that drive business results. Think for instance about enabling users to create music playlist, so that they can find their favourite music easily. You can create new behaviours or focus on existing customer behaviours (e.g. opening emails or sharing images). This could in turn help increase the life time value of those users, which is a measurable business result. Seiden reminds us of the first Agile principle – “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Seiden rephrases this principle slightly to best fit today’s context: “our highest priority is to satisfy the customer through early and continuous delivery of value.”
  3. Outcomes, experiments, hypotheses, and MVPs – I loved Seiden’s point about what constitutes an Minimum Viable Product (‘MVP’) and what doesn’t. “An MVP is NOT version 1.0 of your product. Instead, think of MVP as the smallest thing you can make to learn if your hypothesis is correct”, explains Seiden. He talks about agile projects effectively being a series of hypotheses and experiments, all designed to achieve an outcome.
  4. Finding the right outcomes (1) – For me, the million dollar question behind “Outcomes Over Output” is how teams determine the right outcomes to concentrate on. Firstly, you start with a fairly simple question: “what are the customer behaviours that drive business results?” You set an “impact level target”; e.g. increase the rate at which customers visit the site from once a month to twice a month or to reduce the number of times users abandon the checkout process on the app from hundred times a month to ten times a month. Secondly, once the impact level target has been defined, we can then ask “what are the things that customers do that they predict they’ll visit our site?” or “what are the behaviours that predict a successful customer checkout on the app?” In both examples, the focus is on observable and measurable outcomes.
  5. Finding the right outcomes (2) – Rather helpfully, Seiden shares what he refers to as “The Magic Questions” that we can all apply when figuring out the right, measurable outcomes to concentrate on: (1) What are the user and customer behaviours that drive business results. This is the outcome that we’re trying to create; (2) How can we get people to do more of these behaviours? These are the features, policy changes, promotions, etc. that we’ll do to create the right outcomes and (3) How do we know that we’re right? This uncovers the dynamics of the system, as well as the tests and metrics we’ll use to measure our progress.
  6. Planning around outcomes – Instead of building plans around outputs or features, it often makes makes more sense to plan around themes of work, problems to solve, or outcomes to deliver. Seiden makes the point that the less certain that you are that your outputs (i.e. the features that you want to deliver) will deliver the results you seek, the more it makes sense to plan in terms of outcomes and to build your roadmaps around sets of outcomes.

Main learning point: “Outcomes Over Outputs” does a great job of linking customer focus with specific business results, and is a great read for anyone keen to make the right impact on customer behaviour for the right reasons.

Review: Shift

Having worked on a number of online marketplace products, I’m always curious about other online marketplaces out there. So you might be able to imagine my excitement when I came across Shift, a US-based marketplace for new and used cars. Having bought used cars before, I feel that the used car industry is ripe for disruption and my hunch is that Shift is aiming to do just that.

I can see plenty of room to improve transparency and trust when it comes to buying and selling used cars and I’m keen to learn more about how Shift tries to tackle both areas:

My quick summary of Shift before using it: I expect a platform that enables consumers to discover, compare and buy used cars. Unsure whether cars are bought from dealerships or from Shift directly. Also, wondering whether I can get finance through Shift to help purchase my car.

How does Shift explain itself in the first minute? The landing page of the site shows two women, seated in a car and looking happy. The main strap-line on the site reads “Simplified car buying”, followed by “Great cars. Better prices. Test drives delivered to you.” The main navigation bar in the top right hand corner of the page shows “Financing” as one of the options for people to consider.

 

 

How does Shift work? Shift’s “Concierges” deliver test drives to customers on-demand. After a test drive one can arrange finance and purchase the car on the spot. Shift applies three driving principles to its business, as it aims to “bring trust and simplicity to the peer-to-peer used car market”: convenience, value and trust. Shift sees the Concierge as a pivotal actor as part of this experience as it’s the role of the Concierge “to be your guide. It’s not their job to sell you a car, it’s to help you buy one.”

 

 

When, for instance, I look at a used Mercedes GLE 350 to buy (see screenshot below), a few things stand out to me:

“No-haggle list price” – So there’s no room for a potential buyer to bring the price down!? From a peer-to-peer perspective, I can see how a fixed price creates a lot of clarity and trust for both parties involved in the transaction, car buyer and seller.

 

 

Compare price – I would have loved to compare prices for the specific car I’m interested in. When, however, I click on “Compare” for a a number of different vehicles on Shift’s site, I keep getting a message stating that price comparison info isn’t available.

 

 

Mechanical inspection – Would love to learn more about Shift’s process that precedes the mechanical inspection as shown for each model on the site. I deliberately looked for cars that didn’t just have a perfect list, i.e. all green marks, and I found one (see below). This Toyota Prius (2010) has three body related issues. When I click to see details, the three issue are being explained clearly, as well as their impact on both the exterior and the drivability of the car.

 

Wear & tear photos – For this nine year old Toyota Prius, Shift offers seven wear and tear photos so that I can see clear evidence of the body related issues listed in the mechanical inspection report. I can thus make up my mind – before arranging a test drive – whether I can live with these issues or not.

 

 

Having looked into buying car, I now want to see how one can sell a car through Shift:

These three steps involved in selling a car through Shift feel very similar to selling through Vroom:

 

 

Get an estimate – Getting a Shift estimate for a car to sell feels pretty straightforward (see screenshot below). My only question is how car sellers can quickly figure out whether they’re getting a good price for their car, and how this estimated price compares to what they could get elsewhere.

 

 

How and when do I get paid? Shift will initiate payment to the the car seller at the end of the appointment in which they evaluate one’s car to sell. This approach made me think of real estate platforms such as Opendoor and Nested. These companies will buy your property off you (Opendoor) or pay an advance (Nested) after they’ve thoroughly inspected and valued your home. The comparison with real estate made me wonder whether Shift refurbishes the interior of car or improves the exterior once it has bought the car off you.

 

Screen Shot 2019-03-11 at 09.18.27.png

 

Did Shift deliver on my expectations? Yes. Refreshing to see the level of simplicity and transparency into an experience which has traditionally put the (uninformed) car buyer or seller on the back foot.

 

Related links for further learning:

  1. https://www.autogravity.com/
  2. https://www.lingscars.com/
  3. https://www.vroom.com/
  4. https://shift.com/cars/
  5. https://www.drivemotors.com/
  6. https://broadspeed.com/

Book review: “The Messy Middle” by Scott Belsky

 

I’m sure a lot of us have common misconceptions about successful entrepreneurs and their companies. It’s easy to look at people who’ve ‘made it’ and think that their journey has been all plain sailing. Scott Belsky is such an entrepreneur, having founded Behance, a platform for creative professionals to show off their work, which eventually got acquired by Adobe. In “The Messy Middle”, Belsky eradicates any illusions about the process of creating – whether it’s a business or a product – being painless. He writes about the different stages of a startup lifecycle: the start, the middle and the finish. Belsky makes the point that “it’s not about the start and finish, it’s about the journey in between.”

 

Fig. 1 – Scott Belsky, Navigating The Messy Middle – Taken from: https://medium.com/positiveslope/navigating-the-messy-middle-7ca6fff11966

 

At the start, there’s “pure joy” to begin with. That is before reality kicks in and things hit bottom. Belsky describes the finish as “final mile of journey and the recovery time between one project and the next”, the point where you can allow yourself to take a break and make a change. I, however, specifically bought the book because I was intrigued to read Belsky’s thoughts about the ‘messy middle’. Belsky writes about this period, as a collection of peaks – ‘optimising’ – and valleys – ‘enduring’. It’s this period which benefits from volatility. Volatility being positioned as a good thing might sound counterintuitive to some, but Belsky argues that “volatility is good for velocity”:

“The faster you move, the better your chances of learning and momentum to soar above the competition.”

Scott Belsky, The Messy Middle

 

To achieve this level of velocity, Belsky encourages conducting experiments, and lots of them. Running these experiments means that you’ll be both enduring the lows and optimising everything that works. In “The Messy Middle”, Belsky shares a ton of lessons learned and tips, particularly in relation to those stages of your company or product that are dominated by enduring and optimising. Allow me to give you a quick shopping list of those points by Belsky which resonated with me most:

  • Avoid validation in the form of false positives –  To objectively observe the performance of your new creation or product, put yourself in others’ shoes. Belsky refers to points made by Ben Horowitz about telling the truth in this respect (see Fig. 1 below).
  • Celebrate progress and impact – Especially at the early stages, celebrate anything you can. Whilst you should avoid ‘fake wins’, celebrating quick wins and progress milestones is important.
  • Master the art of parallel processing – This involves being able to focus on a specific problem whilst also churning through the omnipresent anxiety and uncertainty involved in building things.
  • Friction unlocks the full potential of working together – Hardship brings your teams together and equips you to endure for the long haul.
  • Do Your Fucking Job (‘DYFJ’) – Leading a team through enduring times requires many “rip off the Band-Aid” moments. Nobody wants to inflict pain on their team, but quick and controlled pain is better than a drawn out infection. This also implies checking your ego at the door, instead concentrating on what needs to be done.
  • Self awareness as the only sustainable competitive advantage in business – Your sense of self is likely to shift when you’re at a peak or in a valley (see Fig. 2 below).
  • Break the long game down into chapters – Belsky recounts the approach by Ben Silbermann, CEO of Pinterest, who breaks up every period of his company into chapters, each with a beginning, goal, reflection period, and reward. Chapters help break down the long timescale it takes to build something extraordinary. I like to think of them as strategic milestones, each time getting one step closer to achieving the vision for the business.
  • Do the work regardless of whose work it is – Everyone has an opinion, but few are willing to do something about it – especially if it falls outside their formal job description. Belsky describes his marvel at just how quickly an idea takes hold when someone proactively does the underlying work no one else clearly owned. He goes on to talk about how hiring for people with excitement about the idea, ability to contribute right away and the potential to learn is key when assembling a team.
  • Never stop crafting the “first mile” of your product’s experience – Whether you’re building a product, creating art, or writing a book, you need to remember that your customers make sweeping judgments in their first experience interacting with your creation – especially in the first 30 seconds. Belsky call this the “first mile”, and he argues that it’s important to prime your audience to the point where they know three things: 1. Why they’re there (2) What they can accomplish and (3) What to do next.
  • Identify and prioritise efforts with disproportionate impact – Belsky shares a nice prioritisation method by Jeffrey Kalmikoff, which Jeffrey uses to help choose where to focus his energy: look at each item on the table and assign a 3 for very important tasks that would make a huge impact on strategy and revenue, a 2 for something with less significance, and a 1 for something inconsequential.
  • Stress-test your opinions with radical truthfulness – “Sound judgment, achieved through aggressive truth seeking, is your most differentiating and deterministic trait. It’s all about being honest.” This is one of the founding principles behind Bridgewater, the leading hedge funded founded by Ray Dalio. One of the most fundamental principles driving behaviour at Bridgewater is the notion of “Know what you don’t know, and what to do about it.”

Main learning point: In “The Messy Middle”, Belsky has written a book that I expect to be coming back to over the coming years; it’s a great reminder of the realities involved in creating things and contains a lot of valuable lessons learned as well as practical tips.

 

Fig. 1 – Ben Horowitz – Three methods for assigning meaning to hard truths, taken from https://a16z.com/2017/07/27/how-to-tell-the-truth/:

  • State the facts clearly and honestly.
  • If you caused it, explain how such a bad thing could occur.
  • Explain why taking the action is essential to the larger mission and how important that mission is.

 

Fig. 2 – Self awareness, by Scott Belksy – Taken from “The Messy Middle”, pp. 54-56:

  • Self awareness starts with the realisation that when you’re at a peak or in a valley, you’re not your greatest self.
  • Self awareness means understanding your own feelings enough to recognise what bothers you.
  • Self awareness means being permeable.
  • Self awareness comes from chronicling your patterns.
  • Self awareness means dispelling your sense of superiority and the myths that people believe about you.

 

Related links for further learning:

  1. https://www.themessymiddle.com/
  2. https://a16z.com/2017/07/27/how-to-tell-the-truth/
  3. https://www.adamgrant.net/
  4. https://www.mindtheproduct.com/2017/07/enter-matrix-lean-prioritisation/
  5. https://ryanholiday.net/stop-examine-reconsider/
  6. https://blackboxofpm.com/ruthless-prioritization-e4256e3520a9
  7. https://www.lifehack.org/articles/productivity/how-to-learn-what-you-dont-know.html
  8. https://en.m.wikipedia.org/wiki/Stroop_effect

My product management toolkit (33): launch and learn

“Build it and they will come!” I used to work once with a senior executive, who was of the opinion that a product or feature should just be launched, without any testing with customers beforehand. “I know that once it’s out there, people will want it” she’d explain to me, adding that “it’s what people want”.

 

 

Hearing this “build it and they will come” mantra time and time again did annoy me 🙂 At the same time, it did make me wonder whether it might be a good idea to (continuously) release product features without prior customer discovery … What if this executive is right and any new product, feature or service should just be launched, as a way of learning as quickly as possible!?

Being able to ‘launch and learn’ is a vital tool in any product person’s toolkit. I strongly encourage you to avoid ‘one-off product releases’ at any time; what are you going to learn from shipping a product only to then move on to the next thing!? One can debate about when to best learn – should you learn pre-release? – but the main point is that you’ll need to ship early and often to learn continuously.

Basecamp, a project management software compare, does take ‘launch and learn’ to the extreme, they don’t show customers anything until every customer can see it. In the book “It doesn’t have to be crazy at work”, Basecamp’s co-founders Jason Fried and David Heinemeier Hansson describe how at Basecamp:

  • “We don’t beta-test with customers.”
  • “We don’t ask people what they’d pay for something.”
  • “We do the best job we know how to do and then we launch it into the market.”
  • “The market will tell us the truth.”

Fried and Heinemeier Hansson argue that anything you ask or test with customers prior to launch is hypothetical: “Real answers are uncovered when someone’s motivated enough to buy your product and use it in their own environment – and of their own volition. Anything else is simulated answers. Shipping real products gives you real answers.” Whilst I do agree with this line of thinking, I don’t believe in simply launching some crappy product or feature and see if it sticks (just as much I don’t believe in “build it and they will come”).

 

 

My suggestion would to ‘launch confidently and learn’. This means that for each new product or feature you determine – based on your confidence level – whether it needs some form of customer research before launch:

  1. Deliver value in order to learn – You want to be smart about the things you want to learn. The best opportunity to learn comes when you’re confident about the value that you’re delivering to the customer. Naturally, people might not buy or use your product despite the value it intends to deliver, but that’s a learning in itself.
  2. Minimum Level of Confidence (1) – How confident are you? What exactly are you confident about (and why)? The main reason why I believe in product managers adhering to a confidence treshold is to avoid launching products that don’t work or provide an awful user experience. The Newton MessagePad which came out in 1993 is a good example of the launch of an incomplete product, which didn’t live up to its promise. Larry Tesler, senior exec at Apple at the time of of the Newton MessagePad, described Apple’s promise about the Newton’s handwriting capability as a large nail in the Newton coffin. The lesson learned here is that you shouldn’t launch when you’re not confident about the capability and value of your product or feature.
  3. Minimum Level of Confidence (2) – I’ve come up with a number of basic questions and criteria to apply when you’re thinking of launching a product (see Fig. 1-2 below). In my experience, identifying your Minimum Level of Confidence shouldn’t result in ‘analysis paralysis’. In contrast, it’s an important conversation to have throughout the product lifecycle to ensure that everyone fully understands what risks or unknowns are associated with the upcoming release. As an outcome of such a conversation you can decide whether to get customer feedback pre-release.
  4. Make sure you learn! – Whether you do or don’t engage with customers before launch, being clear about what you’re looking to learn from a release is paramount. Like I mentioned above, I view releasing something without learning from it  as a cardinal sin. It’s very important to continuously learn from real users and actual usage (or not) about your key hypotheses. These learnings – both quantitive and qualitative – will give you the data points to iterate or terminate a product.

Fig. 1 – Questions and criteria to check your confidence about launching a product or feature:

  • Internal quality assurance – Have you tested your product feature to ensure there are no obvious bugs or gaps in the user experience? Even if you don’t test with customers prior to launch, you should test some key acceptance scenarios internally before launch to make sure the product works as intended.
  • Does the feature or product touch on core user experience? – If “yes” is the answer to this, then I recommend you do test with customers prior to launch to identify any major usability issues worth solving before launch. You typically need to test with no more than five customers to unearth any critical usability issues.
  • How confident are you? – The combination of low confidence in something which your business has got a lot riding can be deadly. Yes, one can always try to do damage limitation, but it might already be too late at the time of you trying to repair things! The idea behind determining your confidence levels upfront isn’t a scientific one. Instead, it enables a conversation, making sure that people have got their eyes wide open and understand the level of risk and unknowns involved in an upcoming product launch (see Fig. 2 below).

Fig. 2 – Basic confidence levels to consider before launch:

  • High Confidence: Our confidence in the upcoming release is high because we tested it thoroughly internally, have launched a similar product or feature before or if there’s an issue the fallout will be small.
  • Low Confidence: Our confidence in the upcoming release is low because we haven’t fully tested it, it’s based on new technology or creates a totally new user experience.

 

 

 

Main learning point: Even if you decide not to generate customer learnings before a product launch, make sure you at learn after launch. Launch and learn. Don’t launch without learning!

 

Related links for further learning:

  1. https://www.mindtheproduct.com/2017/02/the-life-of-a-product-manager-learning-by-doing/
  2. https://www.intercom.com/blog/shipping-is-your-companys-heartbeat/
  3. https://medium.com/@joshelman/a-product-managers-job-63c09a43d0ec
  4. https://uxplanet.org/10-things-i-learned-from-jason-fried-about-building-products-5b6694ff02aa
  5. http://time.com/13549/the-10-worst-product-fails-of-all-time/
  6. https://twitter.com/jasonfried/status/935555293014036480
  7. https://247wallst.com/special-report/2014/03/03/worst-product-flops-of-all-time/2/
  8. https://www.macworld.com/article/2047342/remembering-the-newton-messagepad-20-years-later.html
  9. https://www.nytimes.com/1993/09/26/business/the-executive-computer-so-far-the-newton-experience-is-less-than-fulfilling.html