The Real Reason Why Your Product Launch Failed

Recently, I’ve found myself getting approached by a lot of people who have “just finished their product” and are looking for their “first marketing hire.”

Very often, these products have fundamental flaws. Sometimes the product is an idea that has been tried many times before, and which the market has shown that it doesn’t really want, such as a platform for micropayments.

Other times, they are ideas where the chances of succeeding against the incumbent are impossibly slim. If you are building an enterprise chat solution, a project management tool, or a Steam competitor, you are simply too late.

The common thread with a lot of these products is that they view marketing as something that is done at the end of the process, to package up and put a pretty ribbon on the product.

If questions like “who is this product for?” been asked, they have either been answered with “Everybody,” or accompanied by unrealistic projections of routes to market. Of course, it would be nice if YouTube integrated with your platform, but you have a two-month-old SaaS app, and that is not going to happen.

Positioning is left to “those clever people in marketing” to sort out after the product has already been built.

If you’re building a competitive analysis, a datasheet, a PRD, or planning to attack a new segment, this job is a million times harder if the product has not been designed with a market in mind.

You might think that designing a product with a market in mind sounds a bit like cheating: it’s not, it’s just common sense. You may feel that having to go out and do the hard yards of competitive research is a constraint on your inner product visionary. You may think you operate with some kind of reality distortion field where you can make products a success through sheer force of will.

Sadly, most technical products are still built without answering simple questions about who the target market is, and what value they will find in the product. It’s easy to blame the CTO for this, but often the CTO just wants to code and doesn’t know any better.

More often, the fault lies with VC firms who throw money at companies on a scale up and scale out model. These firms should be asking the hard questions before the product has finished its development cycle. Instead of hiring hundreds of engineers, they should be funding market research so that engineers time is not wasted building stuff that will never find a market.

There is very little upside for a marketer in joining one of these companies. Who is going to join a company where they are going to have to face investors and tell them that the product was developed in a vacuum? If you’re joining as a humble product manager, you have almost no chance of making meaningful change in a company once the product has reached that point.

Before you build anything or designers have even started to prototype the product, you need to be able to answer:

– Who are the buyers for this product (by title, job function, by company size, and industry)?
– What is the value of the product to that person or people?
– Is this enough of a pressing pain point for them to spend money on this?
– Is this enough of a pressing pain point for them to spend money on this right now?
– What are the alternatives to them buying my product (this isn’t always competitors, sometimes ‘doing nothing’ and ‘building it myself’) are options too.
– Why would they not do it themselves?
– What is my market position or niche?
– How can I position myself to be #1 in my niche?
– Is the niche big enough in itself to sustain a product (i.e. the number of people that actually want ‘Facebook for Dogs’, ‘Uber for Pets’, ‘An on-demand VR platform for gamers’ is likely too small)?

If you can’t answer these questions, how do you know what to build?

When you need to make trade-offs about items on your feature list, how do you know which items to leave behind?

If you can’t answer these questions, then that is a massive red flag and you need to take a step back and do some market research.

Whether that research is talking to analysts in the space, performing a market validation, or talking to potential customers, you will gain insights that will help you prioritize your features, jump ahead of the competition, and position a product that is truly unique in the market.


What Marketers Can Learn From Technologists “Continuous Delivery” Concept

One of the big advances in the technology world in recent years has been the rise of the Continuous Delivery philosophy. Whereas IT companies used to do big monthly or quarterly “pushes” of code, they now push code all the time, or nearly all the time.

The upshot of this is that where it would have taken months for customers to get new features, now much smaller updates get pushed to the customer every day, sometimes hundreds of times a day.

How Does Continuous Delivery Apply To Marketers?

As marketers, many of us plan out quarterly campaigns on Excel spreadsheets, down to precise pieces of content that will be delivered, months in advance. This is how things used to be done in the development world, until developers consistently found that they were delivering projects late, that the spec didn’t match what was needed, and that it was hard to achieve alignment between functional teams. Sound familiar?

We can, in my opinion, learn something from the developers and adopt something like Continuous Delivery for our marketing workflow. Here’s why I think that would be a good idea:

  • Reduce Risk. The main reason for pushing new pieces of content (such as a section on a website, or a piece of collateral) out fast and then iterating is that risk is lowered. Large pieces of content require thorough and detailed checking to catch any bugs, and often need sign off from board-level people (for whom proofreading is a menial, back of the line activity). If you push content out in large chunks every few weeks, there’s often lots of waiting before that content actually makes it live.
  • Freshness. There’s nothing worse than working on a new piece of content, and then having to come back to it and make amends weeks later. If I push content live as soon as it is ready, it’s a lot easier to come back to if a few words need changing here and there. I also don’t have to worry about a backlog of content growing (months old, forgotten about blog posts awaiting sign off). I can concentrate on going to work on the next thing.
  • Customers get new information faster. I think we can agree that customers receiving new information from us faster is better, right? It’s a waste having pieces of content sitting around for weeks whilst waiting for a few changes in wording.
  • Fast feedback. The sooner a piece of content is “live”, the faster we are getting feedback from the market. This can come in the form of marketing analytics, direct feedback from the customer, or other metrics such as lead velocity. Very often, we don’t know the next piece of content that will be needed until we get feedback on how our current pieces of content are doing. As valuable as refining content internally is, it’s never as valuable as getting the content into production. Having content out there in the market will get you feedback that you will never get internally.


  • Cloud software – For this to work, you need to be working with software like Google Docs, or better yet loading content directly into a CMS like HubSpot, Eloqua or Pardot and managing it proactively from there. If you’re passing round Word documents in email with filenames like “Draft VERSION 1 OLD DO NOT USE.doc”, you’re obviously not going to be able to get stuff done this fast.
  • Polyglot teams – This approach works best when you have marketers that can “wear many hats” and quickly make the amends needed to push content into production. You may well have a designer on your team, but everyone should know how to crop an image. You may well have a coder on your team, but everyone should know some basic HTML and CSS. Everyone should know how to use your CMS.
  • No software handoffs – When you’re pushing content all the time, there should be a minimum of Marketing Operations. This means that rather than having to manually set up integrations between your email software, you webinar package and your CMS, all of these should be already integrated.
  • Version control – It should be easy to go back to previous versions of a piece of content if there is a problem. Platforms such as HubSpot support this out of the box through staging environments, version control and ability to replace files such as PDFs on the fly.


  • Some people, particularly when they are used to the big ol’ quarterly campaign, are uneasy about this approach. Aren’t there more errors with continuous pushes? In my experience, no. You get the occasional boo boo with a large scheduled push and the occasional boo boo with a continuous push. The difference with continuous pushes is that pieces of content do not sit waiting for weeks while someone works on a big fix.
  • Percolation. What about allowing content to “percolate” around an organisation before pushing them out? Won’t that uncover new bugs? This works better in theory than in practice. Your CTO doesn’t really want to be the person that tells you you need to rework your entire document (possibly creating a ton of work for themselves), your CEO has a million and one other things on their plate, and people rarely have the time to give to proofreading a huge piece of content. Much more likely is that you’ll spot bugs once things are live through traffic and usage patterns, and fix them quietly.


As a marketer, I want to do everything I can to push new pieces of content to market as fast as I can. I’ve definitely learned a lot from developers who do continuous delivery. Pushing out content in small chunks rather than big quarterly campaigns lowers risk significantly.

If there’s a change to be made, it can be made quickly. In addition, customers get new info faster, and I can review the impact through marketing analytics. Compared to the old way, I much prefer a Continuous Delivery approach.