Building the answer company: Lessons learned in 2021

This article is a follow up to last year's story titled Building Stears: Lessons Learned in 2020.

After the second year of milestones, firefighting, wins, losses and unknown unknowns, 2021 finally comes to an end. I daresay it's been one helluva year.

As usual, the one constant in my journey has been the amazing team of people who work at Stears.

My team of superstars is the reason anything is possible. And, I remain deeply grateful to all of them, both those who are with us and those who have moved on.

The lessons I learned this year were less about revenue and more about the building blocks of a high-growth company. 

And true to my commitment to write an annual summary each year, I have decided to share the four most significant lessons I learned in 2021 from building Stears.

The big caveat is that I only focus on Stears' consumer business in this article, i.e. Stears Business. I have not focused on lessons from our enterprise business, Stears Data. Perhaps, next year.
 

#1 The only way up is customer obsession

'Who is your customer?'

'Who exactly is your customer??'

'What do you know about your customer???'

These three questions, thrown at me by the brilliant Lagos Business School (LBS) tutor and experienced operator, Chidi Okoro, changed everything.

You see, I entered the year confident about product-market fit. After all, Paul Graham argued it's the only thing that matters.

Our 2020 consumer survey told us some customers loved our product and were willing to pay for it. Meanwhile, our enterprise customers convinced us we were systematically crucial to their information needs. This was a major win in Nigeria, where insight and data are not everyday products. So, we entered the year ready to build, build, build.

Unfortunately, this meant we spent more acquiring users than we did talking to our customers. It might sound confusing at first, but trust me, it happens. It's what happens when you talk to customers in the beginning, build what they want, but then stop talking to them about what to build next.

For instance, within six months in 2020, we ran two large scale consumer surveys to understand who our customers were and why they purchased subscriptions. 

But in 2021, we didn't get around to any deep customer segmentation, interviews or profiling until the last quarter of the year. We just never got around to prioritising it.

Instead, we relied on the stories we heard about what customers wanted from the year before. While this isn't always harmful, the problem was that team members didn't always have the same customer persona in mind, so we weren't targeted enough. 

For instance, some of our users have specific interests and don't need all our information. They just need some information, and they need it very fast. So, we needed to deliver that information quickly and conveniently for these users. Yet some others wanted to learn everything and anything; their use cases were different, so they needed different features. But, we didn't pick up on these nuances immediately.

By the end of my sessions with Chidi, I had learnt that customer-obsessed teams have their leaders at the forefront of the customer relationship. They don't simply delegate it to research teams and expect junior team members to extract valuable insight from customers. Instead, they lead these customer conversations; they are always in touch, talking, and engaging. 

Some teams have rotations where all team members, regardless of roles (i.e. engineering, design, operations), manage customer success to stay in touch with the customer experience. The idea is to keep the customer experience front and centre. No proxies.

But in practice, customer obsession is not the product of a single action. It's not a single interview, conversation or product review, and it's not a set of analytics slides either.

It's an operating value; it's culture.

The best leaders start with the customer problem and work backwards. They identify the ideal customer experience and design the teams needed to build that experience. 

Less effective teams might focus on what the competition is doing, what they have seen in other startups, or what the market knows as best practices. But, this approach can create vastly different cultures, products and customer experiences from the customer-obsessed teams.

In my brave new world, leaders lead from the front on customer engagements. Leaders pay attention to operations, design, sales, recruitment and culture. But, they obsess over customers, and they fanatically obsess about building solutions to customer problems and nothing less.

So if there is one big lesson to take away from 2021, it's that no operating value will change your company more than obsessing over your customers.
 

#2 Velocity is the competitive edge, not speed

The reality is that speed matters in business. And in tech-enabled companies, speed is probably your most significant competitive advantage. Many things in the day-to-day operations of your business are slow and can grind you to a halt if you let them. Slow decision making, misalignment, operational constraints and even data gathering can slow down teams, destroy morale and kill momentum.

Some smart people who know a lot more about startups than I do have argued that 'momentum is like oxygen to a startup', and I couldn't agree more. 

But, there is a small caveat; velocity matters more than speed.

In physics, velocity and speed are different things. Speed refers to how fast an object is moving, the rate at which an object covers distance, and velocity refers to the rate and direction at which it changes its position.

It can feel like a subtle difference, but it matters immensely for startups. Startups are often encouraged to fail fast and fail quickly. And this experimental approach serves its purpose. But, it's possible to do things very quickly without making much progress.

And this could happen because of a lack of direction.

In nascent innovation ecosystems like Nigeria, you frequently can't get from A to Z by following a straight path. You might need a short term detour to achieve a long-term goal, e.g. building out some of your infrastructure, launching a training programme to upskill team members or integrating backwards in your value chain to unblock a significant input.

The result is that the team needs to quickly solve a minor problem (the detour) to solve the bigger problem (the customer's problem). When this happens, you need clear goals & enforcement mechanisms that outline where the team is going, how much time they will spend on the detour, and when to kill the detour if necessary.

Our detour was to improve the billing and subscription management infrastructure powering Stears Business. It required learning about the limitations of our existing infrastructure, understanding why the limitations existed, figuring out exactly what we needed to unblock them, and deciding whether or not we needed to build or buy a solution.  

Today, the result of our detour is a Google-backed subscription division focused exclusively on subscription management. But, reaching where we are today required us to rapidly build prototypes to test limitations and use our goal setting tools (Objectives and Key Results) to explicitly identify what we were going to do or not do ourselves.

In my experience, the secret to achieving velocity (as opposed to speed) is ensuring your daily activities are tied to clear goal-setting mechanisms like OKRs. It ensured that as we got faster, we didn't just build anything faster; we built features to achieve our goals faster.

This year, I watched our product team ship faster and faster every quarter. By the end of the year, the team was in the zone. But, it also showed us that it's important to be clear about the direction you are going in. Otherwise, your detour can change your entire journey (a double-edged sword). 

We are still far from where we want to be. Our customers are banging on our doors with unmet demands. But, we haven't lost direction.

Even the fastest teams need 100% clarity on applying their speed. So, velocity will always be important for high growth teams.
 

#3 It takes time to build experience about what works

It takes exceptionally patient and determined leadership to persevere through the continuous process of building a great startup.

It takes even longer when you are building a company like Stears. Stears is in the business of answering questions, and we use data to help our customers understand African markets.

We are the answer company.

However, our customers need to trust our data & insight. We cannot build that trust overnight. But as we grow, we become more intelligent, our information base grows, and our customers trust us more. There is value in compounding.

Our ability to extract and classify the available unstructured data is the opportunity that excites us. But, our team always has to deepen its knowledge and expertise, and depth is essential.

For instance, our data team obsessed over the digital economy this year. We spent countless hours running daily knowledge sessions designed to help us better understand the frontiers of almost every critical sector on the African continent. It was necessary and will always be required, as long as we leverage human intelligence.

Unfortunately, our human biases sometimes slow down our ability to learn. 

Great teams are invariably experimental and require a willingness to fail. But, because human beings are biased to see the world as simple rather than a complex web of interrelated connectors, we often fall for narratives that fit our pre-existing view of things. Therefore, we are more likely to suffer from confirmation bias, attribute correlation to causation, and fail to put our assumptions to the test. In essence, we do not design processes that invalidate our opinions.

But, as you interact with customers, you learn about the real world. The customer feature you think will be the killer acquisition move for your startup becomes the dog that's dead in the water on arrival. So, teams must learn to swarm in on what's happening and check their assumptions.

In these instances, you often need time to know what works and doesn't work.

Here's a practical example; Stears Business runs a freemium model where users can register for free to access some of our content. These registered users can read some of our articles but need to upgrade to read all of them.

Inspired by some promotional emails I received for another freemium product, I recommended that the team place calls to action (promotional nudges) in our daily emails to registered users, inviting them to subscribe.

You would expect these calls to action (e.g. 'Go Premium for ₦10,000 a quarter') to positively nudge our users to subscribe. Well, after running the experiment for a few weeks, the results baffled us all, and it was the opposite of what my brain told me would happen.

We discovered that the higher the frequency of the calls to action in the emails, the higher the decline in subscriber acquisition from email sources, month-on-month.

Incredible.

Without the experience of running this experiment ourselves, we would not have believed it. You might even be reading this now and think the experiment was the problem. 

This is just one example of a lesson we learnt over time, but we have others. We haven't hit our peak when it comes to experimentation and testing, but the team continues to learn. 

As we continue to build, its experimentation to the top.
 

#4 Insist on the highest standards

The last and final lesson of the year is something we have always been particular about at Stears, but we learnt to double down on this year, especially as the team expanded.

A few years ago, I was inspired by Editi Offiong's 'Manage it like that'. In it, he satirically articulates the tendency of Nigerians to do a shoddy job and then demand the customers manage it like that. 

Artisans deliver poor craftsmanship. Tailors produce mysterious outfits. Analysts poorly interpret trends. And engineers ship buggy code. But in many cases, Nigerians just normalise this behaviour and make peace with the fact that 'na so dem dey do am'.

But, this is the hill I am willing to die on because I do not want to manage. I am willing to be patient as things improve, but I refuse to accept them as 'okay' while waiting.

At Stears, quality is our differentiator, and the only way to consistently produce quality output is to insist, every day, on the highest standards. It's a cultural thing, a process thing and an everyday thing.

Some of our Premium readers may recall our brief foray into podcasting. Inspired by the need to explore alternative forms of distributing our content, the team explored podcasting. We recorded one episode as an experiment.

From the experiment, we learnt two things. The first was that people did enjoy listening to our podcast and would consume it. And the second was that with the resources and expertise we had, we would not be able to consistently produce a high-quality podcast that would create value for our users.

Hence, we paused the podcast.

It wasn't our best moment, but it was a proud moment. It is necessary for a team that consistently wants to set the gold standard for African information. [P.S. we will be back with a podcast!]

I will also add that high-quality standards are often domain-specific, and you have to build them in different domains. You may quickly understand what high standards look like in software development, but that does not automatically make you good at spotting high-quality design work. Each area of expertise has to be learnt and mastered, and you have to put in the work to become the very best in the various things you do.

It's not pretty, it can be excruciatingly time consuming, but for companies like ours, it's worth it. In my world, if you want to be big, you have to find something that makes you stand out from the crowd. And quality is our differentiator. 

These four lessons bring me to the end of my lessons from 2021.

As the year ends and we step into a new world, it's time to hit the reset button. It's building time. And as usual, there is nothing left for us to do but build, build, build.