In his first attempt to build and sell a product, Giles Palmer failed pretty badly. It was 2005, and he had just released Magpie Search and Alert, a vertical search engine product for law firms and banks to find specific for them documents such as patents, court rulings, financial statements, etc.
His sales manager at the time had convinced Giles that there was a good use case for such a product. He had sold information to what are called librarians — researchers within these organisations that compiled specific documents for partners and associates. If librarians paid for different services like Factiva and Lexusnexus, surely they would use a particular search engine product. Giles raised half a million pounds and the work began.
Six months after the product had been released, still not a single librarian had bought it.
Building a sellable product, it turned out, was very different from building software. Giles had been doing the latter for the past few years, operating an IT services company, that built open source tools for local governmental authorities. Their last project had been a search engine. Giles had decided to turn that codebase into a product and sell it as a solution to the first problem he had come across.
“We didn’t do enough customer and market research; we didn’t investigate the problem thoroughly, we didn’t have the right long-term direction, solving a big problem. As a CEO, I should have had a much deeper understanding to avoid making such an assumption.”
Folding the company was heartbreaking for Giles. Especially when all the people around him kept saying how much they loved the company and kept asking him to keep going. “You are not just failing yourself; you are failing others who have put their heart and their soul into it.” It’s a morale killer.
Moving forward, Giles had to reevaluate what made products “sell-able” and how that advised product decisions.
He figured it out. Twelve years after the failure of Magpie Search and Alert, Brandwatch is thriving with nearly 400 employees spread in 7 offices, counts over 1,300 customers, and has raised $65 million in VC funding to date. In this exclusive interview, we uncover how Giles learned to make product decisions at the start and built an organization to handle them at scale through what are called Magic Circles. Beyond the technicalities, that journey is about answering the biggest question every product company faces: What makes an idea a viable use case worthy of spending time, effort and money building.
What are the right signals?
It was while Giles was trying hard to sell Search and Alert that the first idea of Brandwatch was conceived. Review sites, blogs, and other user-generated sites were on the rise, and more and more people used them to express opinions about brands. The volume was quickly rising, and Giles wondered how on earth would brands make sense of that volume of information — gather it, analyse it and take appropriate action. Could a product solve that?
Even when mentioned in passing, that idea generated far more curiosity than Search and Alert. Keen to create a product company, Giles noticed that soon enough. He needed far more validation this time around. The more sceptical the people he talked with, the better.
The conversation that tipped Giles was with an investor:
‘If I send you a short email on Friday afternoon that summarises what everybody has said about your company over the last week and compared it to one of your competitors, would you want that email?’
‘Yes,’ the investor answered
‘How much would you pay for it?’
‘I am not sure, but I would pay for that.’
Market research agencies like Nielsen were already working on similar products, which was a further validation there was an actual use case for it.
To stand out, Giles pushed the limits to see what was the gnarliest of problems. How do you process and make sense of the amount of information that is out there?
“Can we build an automated sentiment analysis engine?”
He posed the question to one of his first hires — a PhD data scientist. Remember, this was still 2006. Deep learning didn’t exactly exist.
“Not in the general sense,” the data scientist answered. The reason was there would be too much noise. “You can do a decent job if it’s for a very specific domain.” Think How good are Sharpies for writing on paper, kind of specific.
Clearly, it was almost an impossible problem to solve. That was the third piece of validation Giles needed.
“I would argue that going after difficult problems, gives you the benefit of having a very long-term product direction.”
As long as the problems carry value with them, the harder and more interesting they are from a solutions point of view and the earlier you get into the market and the further you go, the harder it is for people to catch up with you.
Giles had as good of signals and ingredients for the success he was going to get:
A big gnarly problem that gave a longterm vision
Proof from the market that the challenge was big enough
Positive signals the solution was sought after, and people would pay for it
There was no Plan B. No distractions with other ideas, no easy way outs, no giving up. It is something Giles believed was key to building products.
In the first five years of Brandwatch, the only two people responsible for the product were Giles and his CTO at the time, Fabrice Retkowsky. There were no product managers. “In hindsight a huge mistake.”
They didn’t track usage; they didn’t spend enough time understanding the customers and had no dedicated product design.
“It’s a miracle we built anything that people liked. I’ll put it down to hard work and luck! ”
Eventually, Giles hired the first product manager.
The person’s responsibility was to be information gatherer — strategy from Giles and engineering capability from Fabrice. But he also had to add the elements of signals from customer and market competitors. The product manager would then sift through that information and prioritise. Deciding on that balance in mind is the art of the product manager.
As the company scaled, it became clear that gathering signals from the market and the customers were much more complex. It required direct input from sales and marketing that had much more direct contact with customers and prospects.
Without all the information in place, product managers couldn’t make decisions without heavy input from executives. Something which as the company was growing was becoming more and more unscalable. Especially as the products were getting more complex, the data bigger and richer and the potential of technology ever vaster. “The possibilities for productising the data were endless.” But would anyone have any need for such products?
The coordination between teams with mutual dependencies was not working well. Product design often wasn’t invoked early enough nor was product marketing given enough time and information leading up to product launches.
Everybody had a low degree of frustration pretty much all the time.
“In the drive to become great at marketing, sales, engineering etc. we had become siloed.”
Some of the more enlightened and proactive people in the organisation began to form collectives naturally to make more holistic decisions. Once the rest of the organisation saw what these guys were achieving and how happy and productive they were, Giles decided to encode it. He gave it a name and wrote it down as a framework. The Magic Circles.
The magic circle
The Magic Circle is a cross-functional collective comprised of a product manager, product marketer, lead designer and lead developer. There is one for each product. Each member has decision making responsibilities, which means that for each product commercial, engineering, design and product matters are factored in.
It was a framework for making decisions at scale, where the ones making the decisions are the people closest to the customer and the market.
In making a product decision, the Magic Circle aims to answer the following vital questions:
Would it align with the strategy and mission of the company?
Would anyone have a reason to hire such a product?
Are there any more signals?
As the Magic Circles worked around these, Giles’s task was to make sure they had the right environment.
Let’s take the questions one by one.
Would it align with the strategy and mission of the company?
Aligning with the long-term direction and strategy is key to future-proofing a company. Some key questions need to be answered in a clear direction:
What do we want to do?
Where do we see the market going?
Where do we want to go?
How do we see the product evolving?
What problems are we trying to solve?
What bigger problems could be solved?
Remember, the bigger the problem you are solving, the longer term product direction you are going to have and the higher your chance of survival.
Further, the strategy needs to be viable and practical. That is especially key when it comes to companies so heavily using funky technologies like machine learning and AI. The more sophisticated these technologies get, the more carefully aligned with practical use cases, they need to be.
This is where the mission comes in.
The mission of the company is to ‘To create a new type of intelligence by bringing structure and meaning to the voices of billions of people.’ That means building intelligence into their products is a core strategic direction. Executing on that is still within the Magic Circle’s remit.
The big question is — Is that product going to make the user’s life easier?
Would anyone have a reason to hire such a product?
In the magic circle, the most important task of the product manager is to find whether there is a viable use case for a product stemming from the idea. The framework that works for Brandwatch is Jobs-to-be-done. First used in marketing through its early architects like Bob Moesta, Clayton Christensen, and Chris Spiek in the last few years it has proliferated in the space of product management.
The framework’s implementations have slightly different flavours. The ultimate question it aims to answer is What job would the product be hired for. The job, in essence, is what the person is trying to accomplish in a given circumstance. Because if there isn’t a job to solve for, there is no point in a product’s existence. It’s the ultimate use case test.
The product manager frames the decision functionality around the job that it’s being solved for and identify how Brandwatch tests if it’s solving the usage. It requires identifying targets and characteristics.
It starts at a high level, by understanding, why brand managers hire Brandwatch in the first place and what it helps them do.
They need to have insight from the conversations out there. For example, what are the conversations around airlines?
Then it’s looking more specifically at what airline brand managers need to know. They need to see how different topics change the overall conversation and sentiment. How do delays affect the overall conversation?
That sort of investigation and thinking inspired the creation of Quick search functionality, which gives an immediate picture of how the conversation changes.
That investigation needs to be matched with tracking many more market signals.
Are there any more signals?
They also have a comprehensive way of looking into the signals of the market. It’s a combination of the following
1. Looking at product usage
2. Asking customers directly in the application
3. Visiting them and ask face to face
4. Checking out what competitors are doing
5. Getting a group of power users in a room for a few hours and brainstorm
6. Tracking feature requests over time and see if the need persists or increases
7. Looking at the effort required to build things, and we start to stack rank our feature requests.
Looking at this, they take into consideration releases and whether there is a set of features and functionality that can be applied to a specific job in a coherent, marketable group.
“And we talk about it until we all want to kill each other.”
Does the Magic Circle have the right environment to thrive in?
Each magic circle has a weekly meeting where they go through product performance both regarding usage but also commercially, and also talk about delivery and product planning. All Magic Circles then feed into the executive Magic Circle, which has the CMO, CTO, Head of Product, and Head of Product Design. On a quarterly basis, they have bigger planning meetings.
The magic that makes the magic circle work so they can make those hairy decisions? A no blame culture.
It comes from an understanding that people need to feel safe to be able to express their opinions.
It starts with a bit of matchmaking.
“If you watch close enough, you see people gravitating towards each other, that is your first sign that they would make great buddies in a magic circle.”
They can be collectively intelligent, only if there is respect, empathy and trust. That is how the chemical reaction happens. That requires Giles and other executives to spend a lot of time trying to understand if teams jell well. Giles often sits in their meetings to observe how their discussion go.
With a direction in mind, well-crunched customer signal data and respectful teams, decision making at scale becomes possible. In fact, it becomes easier.
“People will always have an incredibly hard time making decisions on their own because no one can deal with the responsibility of that.” It is as difficult for Giles as anyone else in the company. Since he is instigating more collective decision making, Giles takes very few decisions on his own and leads by example.
The Magic Circle is also an alignment instrument, as, beyond decision making, it is responsible for the actual execution as well as internal and external communication about it.
As you have probably gathered by now, it’s all very calculated in the product decision land of Brandwatch. But if you want to be a true innovator, not everything should be as well calculated. Which is why Giles makes two notable exceptions.
Technical breakthroughs
On the day I spoke with Giles, Brandwatch had just released a new version of their audiences product, which was a 100 times speed improvement on the product. Even the most complex searches and analysis of our database of over 500m people now takes just a few moments and will see results up to 100x faster.
How this came about was from a hypothesis a developer had about how it could be hugely improved. “You have a month to prototype it,” the CTO said. It looked good, so he got another three months to develop it with two of his colleagues. They finished it in six but succeeded to deliver the improvement they had promised.
“To have this kind of breakthroughs you have to have the culture where someone can just raise their hands and say I have an idea, give me time to explore it.”
The crazy ideas
There are the ideas that have no backing for. There are no signals to justify them; there are no obvious reasons the problem is even recognised. Every company needs them.
Giles has had one of them for seven years now. He has never been able to get a go-ahead by his executives. He has never single-handedly decided he is going to do it just because he wants to. Until now.
“This idea is festering in my head.” It reminds him of the time he was 11 and was convinced of the bike he wanted to make. The shop owner tried to convince him to go with another, but young Giles would have none of that. In his heart he was convinced.
He may not have the validation, but Giles is convinced he has to take risks.
“As the company has grown, it has become less risky and, borrowing from Nassim Taleb, possibly less anti-fragile to. We need to inject more risk — I just need to convince my CFO, which is not going to be easy.”
A final piece of advice
Despite looking for processes to scale product decision making, the truth is that much of it is down to luck. “You always have to be suspicious of explaining things retrospectively.” Because even with all the signals, frameworks and strategies in place decisions are never blindingly obvious, never.
Giles and Brandwatch are still trying to solve that bigger hairy challenge of making sense of all the online language. In the last 12 years, they have come a long way and have gotten closer to it. But also the amount of the conversations out there has grown exponentially.
We have many more articles and podcasts about making better product decisons in SaaS. Have a browse in our redesigned Learning Hub.
