Product Strategy
Product Management Perspectives
I spent years trying to second guess how a mature software product business should work. In the early days other software companies seemed more polished, and more deliberate.
Eventually, by asking lots of questions at every opportunity and reading more and more, I did begin to see a pattern.
Start ups are founded by two different groups of people: entrepreneurs and engineers.
When an entrepreneur starts a software company, they set out on a deliberate journey to address a particular market they have identified to follow, and if they know how, they apply a product management mindset to making the most of that opportunity. Other businesses like ours get started by engineering, beginning with a belief they can build something better than the presently available products in the market. They are eager to build great software and put it out there.
The product management entrepreneur focuses on building their value proposition, meaning their market research, product vision, and their message; only then do they begin to build their product, targeted at a specific customer niche with a specific set of critical problems. When done well, these businesses create a very clear message in a clear target market, even if engineering may lag behind their intent. Their priority is applying effort to market and message before engineering starts.
The engineering-led group focuses on a problem they think requires fixing. It’s something they understand to have been done badly by other companies, often taking a shorter route to satisfying themselves that if others occupy that category, then the market must exist and be big enough for new entrants. Their priority is to apply engineering ability to produce software that is rock solid. Their mantra is, “If we build it, they will come.” They put far less thought into on the market, message, and positioning.
As companies mature, the product-led businesses of the entrepreneur, that cannot acquire the engineering quality will fail because of customer issues, whilst engineering-led companies that spend forever being technicians and don’t follow product management practices will fail because of lack of market fit and efficient scaling up of go to market.
In our case, we were engineers, and we initially made a series of product management mistakes that got us into tough conversations with unhappy customers and confused prospects. We tried to solve too many customer problems without first answering all the right questions, and applying sufficient analysis to separate features that some customers wanted versus ones that all customers would pay for. We were not clear enough in what we wanted to say about our products to the market or why. We had not done enough quantification of what the customer needed most.
When we did focus on the right pain points, there were occasions when we didn’t take the time to develop the market message and narrative that explained ourselves to a business audience. We were much better talking about our rock-solid technology and how that worked.
We needed a better way of working, identifying potential innovations with customers, quantifying their impact, prioritising the most important customer needs, and orchestrating a smooth process of delivering the most important features to the market. In time we learned all these things.
Continuous Innovation
As time went by, our customer’s needs, and the services they needed, naturally changed too, impacting their workflows and their business rules that governed what they did. Through our business evolution, consumer markets shifted from High Street to online, business cycles shifted, and economies expanded as the banking crisis faded then contracted again during Covid. Regulatory compliance changed the face of data privacy with GDPR, and geopolitical factors brought about instabilities like Brexit and a US / China trade war.
Needs changed as the world digitized, and our knowledge of how best to service the market evolved too as we learnt more.
In the middle of this, we needed to make product decisions and generate sales.
Our customers needed innovation, we needed to work out what innovation, using quantification and testing.
Neither Alex, who’d become our CTO, nor any of the rest of us ever truly had foresight to know where our product needed to be in two years time. He learned, and we all learned, to recognize this change continuum as a fundamental thing in our own product management and build approach.
It meant that as we continued to solve critical customer problems, our solution would always be incomplete and the context in which we were operating would continue to be disrupted. Starting out, the only way to use our software was as a salesperson with a computer. Within a few years it had to be available on mobile and in contact centres, customer portals, and high-volume, high-performance ecommerce websites. It contained deeper data privacy and worked not just through a user interface by through programmable APIs as well.
Like most CTOs, Alex never had the budget to grow engineering at the same rate as customer requirement growth. Instead, he validated each innovation with the customer before it progressed, then orchestrated engineering talent in an efficient, repeatable way to deliver in the right areas.
Common Customer Needs
What kept us relevant and on track was simple: Our products were designed whilst sitting with customers, talking with customers, listening to customers, and quantifying what they needed. Alex and Fawzi, who became our chief architect, had always worked closely with customers since our days at the broadcaster, and knew the process of building products relied on continual good customer input and measurement. They’d spend days at the desks and in the meeting rooms of our key customers and getting their input to help us solve their critical problems.
At the start, key customers were any customers we could find. As we grew, key customers became our biggest ones, our most successful adopters, or most innovative ones. Being mindful of talking to the right sort of customers who’d take discussions in a productive direction was vital. The customers I describe had real skin in the game with our business, so they were focused on what’s most important, rather than less relevant product edge cases. Fawzi told me, “I’m happiest when they’re willing to challenge us, not just validate us. If they offer no challenge, I’ll go elsewhere.” Sometimes these people were our brightest prospective buyers, and they were often on the front foot of new needs. We developed scoring to quantify how close each customer was to our ideal profile. This helped us pick the right ones to learn from and weigh the quality of the feedback we had.
Also, Alex and Fawzi talked to lots of them. Whether it was a first attempt at a product being designed from a blank sheet through to our advanced offerings where we wanted to tweak what we provided, they aggregated several customer views and perspectives, seeking commonalities and differences in needs. That way we build products to address the largest pain points for the biggest group of customers.
Feature Payback
As we got better at prioritisation, these customer conversations began to establish data points from which we could make investment decisions. Each time a new pain point was identified and discussed; it was like panning for gold. Was it a big enough pain that they’d pay right now to fix it? Was this pain point underserved in the market, or were there companies lining up to provide a quick and cheap solution? Was this pain point in or adjacent to our niche, where we were experts?
Over the years we built up some science around identifying the right pain points—the critical, underserved needs, additive or adjacent to our existing product.
Firstly, Alex and his team recognised that there was a broad universe of problems everywhere. We had to zero in on the problems that most companies in our niche would pay to have fixed. There were some annoying problems that some businesses might pay to solve some of the time. We really tried hard not to get involved in these problems. It was not worth it.
We learnt that lesson the hard way whilst trying to build a highly complex telecom inventory management system that was a bit off grid for us, and in time we learned it was not something lots of customers would routinely buy because the refresh cycle of their existing software in this space was very slow. Managing massive technical networks was hard, and once a system was set up and working, it was handled with care. And they only needed one of them. Even discussing replacing such a system drew wide-eyed, terrified responses from the customer teams involved. No, sinking months of engineering time into that white elephant was a good lesson in what not to do. We needed a definition of what would pay back!
We used a checklist and a score of the customer pains we identified. Top ranking were the ones that occupied the thoughts of the customer, happened often in their business, and for which they had no solution. Such things were painful, could not be ignored, and were consuming time, resources, and money; and unless solved the customer’s success was in real trouble. In these cases, they had left them with no choice but to act.
In discussions Alex or Fawzi, would listen out for customers to say, “It’s costing me time, my valuable resources, and my market opportunity.” Sometimes the pain was acute; once a customer told us they had to stop selling because the order fulfilment on their sales was such a mess, they were losing money. But often the pain would be more of an ongoing daily grind; we’d see for example their current system was glacially slow, and salespeople were stuck doing admin and form filling for hours a day.
Alex and team had to think in terms of creating customer value the fastest way they could by completing only the jobs strictly necessary to deliver product that the customer would pay for. That usually meant compromises against his ideal solution. He had to be clear on what interim solution would sell and solve a basic need, and how it may be improved over time, and then balance future roadmap commitments with paying off the technical debt of these initial shortcomings.
Working through iterations we soon learned what was going to pay back and what was not; and provided we followed the rule of providing interim, tightly scoped solutions without heavy investment up front, then we maintained flexibility.
Final Thoughts:
In this note, I reflect on the evolution of our product strategy at CloudSense, highlighting the challenges we faced as an engineering-led startup and the lessons we learned in aligning our product development with market needs.
Key Takeaways:
Balance Engineering Excellence with Market Needs: While building robust software is crucial, it's equally important to understand and address the specific problems of your target market.
Adopt a Product Management Mindset: Transitioning from an engineering-focused approach to one that incorporates product management practices can help in identifying customer pain points and delivering solutions that resonate with the market.
Prioritize Customer-Centric Features: Distinguish between features that some customers desire and those that all customers are willing to pay for. This ensures efficient use of resources and maximizes market appeal.
Develop Clear Market Messaging: Articulate a compelling narrative that explains your product's value to a business audience, beyond just its technical capabilities.
Embrace Continuous Innovation: Stay attuned to changing customer needs, market dynamics, and regulatory environments. Continuously innovate and adapt your product offerings to remain relevant and competitive.
By integrating these principles, startups can navigate the complexities of product strategy, ensuring that engineering efforts translate into market success and sustained growth.