Your Team, the Product, its Customers or your Client?
Which one gets the final say in Product Development?
In my day job, we build tech products for our clients. Our clients are generally non-technical founders, and they are with us for the long haul. We make life far easier for them by bringing both product and technical expertise to the table on day one, when all they want to do is get their idea to market.
If you were embarking on building new tech and you didn’t know how to, wouldn’t you want an experienced and already functional product team of smart people all ready to go, and behind your business idea on day one? Or would you rather spend your time and money attempting to find and hire the right people, to build your own team, all from scratch on day one? with the limited capital that you have? It is definitely a choice you have to make at some point, and frankly, time and the job market is not on your side to go it alone without the help of experts.
We provide the whole product team for our clients, from soup to nuts (end to end). Our client provides the vision and the evolving business strategy, and we construct and manage the product strategy and product discovery and delivery that delivers results to their business. The equation in tech product is simple to understand, but far from simple to execute:
Changes in Customer Behavior — lead to more Product Outcomes — leads to realised Business Outcomes — leads to realised Business Impacts. (the kinds of impacts executives care most about)
Contrary to very popular belief, or what people in business want to believe, it is not as simple as: the founder/boss chats to some customers, figures out what to build, then instructs their dev team to write some code, and 💥 , the customers love what you built, they buy it, and 💸 is in the bank — that is not product development at all. This ideal is just a well propagated myth.
In reality, product development is really hard work, and it is a case of continually: discovering, innovating, building and testing an effective product that creates a sustainable business over the course of years. The primary activity is not building software, but exploring out what works and what does not. Such that, what is built fits a market of buyers, long before the financial success and return “in” investment is actually realised (let alone realising any return “on” investment!). Writing software is only a part of this. A significant part, but nonetheless just a part.
So, if you are only using your smart developers to write code, guess what? you are only using half of their value, and you will drive them to build the wrong thing.
So, given the nature of the trusted relationship we necessarily have with our clients, and from the perspective of the product team (managing the product strategy), decision making quite often comes down to prioritising what is done next against the needs of several parties, (each of which has their own important needs):
- Our Client (our partner, and the one who pays for our services)
- Our End-Customers (those that buy/use the product)
- Our Product Team (those that design and build the product)
- The Product (The thing that generates business results)
These needs of these four things are all important, and where to focus at any one time is necessarily a tension between these things, that we need to preserve.
The only real difference between our business and every other tech product company is that: we have a Client, who pays for a product strategy & execution service that we provide them as a 3rd party to their company. It requires a great deal of trust and care to work effectively and efficiently. Without trust, its just execution for them. Whereas most tech product companies don’t have this kind of “trust” boundary built into their organisation, the product team is implicitly trusted by the organisation — there is no Client. (Unless perhaps, the company artificially creates some kind of HiPPO stakeholder role or controlling executive, who thinks they should be dictating the product from some other part of the company— which naturally creates such a trust boundary — and an a highly in-effective one at that!).
Our business model isn’t without its challenges of course. It is predicated on having and maintaining a trusted partnership, which has to be earned and managed for the long haul. Especially in tough times, like: when all the capital is gone and the product is not performing well enough in-market. Hence why we invest equity in our client’s business as well, so that we are in it together.
Expectations
Given that our Client is paying our company for a service, the usual expectations around delivering a paid-for-service still apply to us. No different than say: hiring a builder to build your new home.
Common top challenges are: (1) It always feels more expensive than doing it yourself. In this industry, because you only see the tip of the iceberg of the outputs that are delivered (i.e. only see the App UI), and not the preparation or hard work that went into designing and validating it, and (2) in “product development” positive results are never guaranteed, no matter what. Not even if the quality of our service is absolutely perfect, and top notch. No amount of managing the delivery of tech outputs that are created guarantees successful business outcomes. Product development is exactly that, “development”, a.k.a Research & Development (R&D). This fact is so poorly understood outside the tech industry. But is a very real thing, that more often than not leads to all kinds of disappointment for the uninitiated.
In fact, in tech, most of the time, the thing being built is being built for the very first time. It is being built for a new set of customers that is not well defined nor well understood, and it must create changes in customer behavior that have not been done before. On top of that, the underlying platform of wiz-bang tech is forever changing (month on month, year on year), and those doing the building (the techies) have to keep up with all of that too.
To the naked eye, none of this is visible at all. It may seem like building a tech product should be like building a new custom home, but it is not. Building homes is done with standard materials, standard tools, standard practices and with quality and safety standards such as building codes. Success and the outcome is somewhat predictable nowadays, which is why you can view your home in some web page before the land is even cleared of the thorn bushes! You pick your unique vision for your new home from a catalogue, then its location, price it all up, schedule it out and someone builds it for you! You just pay the bill, and move in on the move in date and you are all done. All very predictable stuff.
But none of that predictability actually exists in the tech industry. Which means, in fact, that just about everything that is done in tech is brand new, and those we are building for are also largely unknown to us! It all needs to be learned and discovered along the way. Yes, we have patterns and templates and basic things like that, but even those still need to be realised on the ever changing underlying technologies we have to deal with too. And that takes oodles of experience, and tons of research and development to build something that works reliably, let alone something that customers want to use or buy.
As an industry, we do a good job of hiding this uncertainty aspect to people outside the industry. Not intentionally, its just that we accepted it long ago, hand have moved on to dealing with it in more effective ways. The serious problems begin when people outside the tech industry enter the tech industry and fail to grasp and confront this reality quick enough.
The learning curve of that journey is steep and unforgiving, and many newcomers try to ignore it to their inevitable peril, months to years later.
Outcomes
So, with all that in mind, how could this ever work properly?
Let’s say that you are on a product team trying to figure out whether the feature that was just built (over the few days or so) was actually effective at delivering the business results we were hoping for. (No matter where the idea for that feature came from).
Lets say, for arguments sake, that we built FeatureX because we believed FeatureX would convince more customers to convert from trial users to paid users. Yay! more paying users on the platform equals more revenue from those users, equals more time to build more things in the product. So we built it — obviously!
Now the real question is: was FeatureX effective at creating the intended outcome (i.e. the user conversion) in-market? and how effective was it? Because, we also need to know when FeatureX is performing good enough, so we can move on to focus on the next thing. Otherwise, we have to keep on iterating on FeatureX to make it more effective, otherwise we don’t achieve the outcome we wanted. In which case, we should abort, and have a rethink — may not be so obvious why that didn’t work, but it didn’t nevertheless!
Business outcomes (i.e. more user conversions, and more revenue) are not created directly by product teams, nor by our clients nor their sales and marketing teams. It does not work like that. Product outcomes are created directly by product teams. Business outcomes happen because of the existence of successful product outcomes. (Without which there can be no business outcome). You see, most people incorrectly think that the product serves the business, but in actual fact the product creates the business. Business outcomes are in-fact trailing/lagging indicators of product success. They don’t exist and cannot be created on their own. They result from successful product outcomes.
So, what creates product success?
More product outcomes. But, what is a Product Outcome?
Let’s say for simplicity, that product outcomes are things like: customer acquisition, customer activation, customer retention, customer referral, etc. (to borrow a familiar model). These are in fact very generic product outcomes that can apply to just about any tech product. But you probably understand what those things are. Actual product outcomes apply to the specific product. So, for example: an e-commerce product that sells kitchen knives in a product catalogue, would have specific product outcomes related to customers buying knives. “Buying a knife” is a specific product outcome here. It is also easy to measure. And being measurable is key for product outcomes.
OK, so what creates more Product Outcomes?
Changes in Customer behavior (CICB). What creates Changes in Customer Behavior?
The R&D that product teams do to ensure that they build effective features that users actually use in the product. What is that R&D?
We call that Product Discovery and Delivery. What does that mean?
It means continuously running experiments on new ideas on users in-market and measuring their effectiveness in changing actual customer behavior. Then, when we get a positive signals from customer behavior changes, iterating on that until that feature proves successful, with data. Only then are we done.
Does that done feature look anything like the original idea at the start?
Sometimes! but more often than not it does not. Why is that?
Because most of the ideas we start with have to necessarily change to fit the market and customers we are testing them on. And success here for the vast majority of ideas is largely unknowable before we start experimenting (no matter how obvious to the person with the idea). Which is why most of the ideas we start with don‘t succeed, and many will be proven to not succeed. Which means that no matter who they come from or where they come from, ideas may not succeed at all. And that is not obvious to those who come up with the ideas. (In a lot of cases, it was not even considered a possibility that it would not work!) The success of an idea relies on experimentation and execution in-market. It matters not where the idea came from.
Trust
OK, so given that, what has prioritisation got to do with all this and our Clients?
Well, if you think about it. Understanding how successful ideas are realised into products (that actually work in-market )— as described above — makes you realise that no one person has a monopoly on, or has the authority on, ideas that will actually work. They are all guesses, no matter who has them, some better than others, but most simply won’t work. All ideas must be vetted and tested properly and comprehensively, and this work is actually the hard work of product development.(which accounts for why so many companies don’t do this kind of work, nor do it well enough to succeed at it).
Conversely, the much easier (and more visible) work is to: define/refine and plan features, and manage delivering them on time and on budget. Which just amounts to “busy work” that pays little attention to whether the delivered features actually work or not, in-market.
Now you know why 90-something percent of all tech startups fail in their first few years — by building the wrong thing using the easy way.
So, our Clients have to recognize, that no matter what customers they have spoken to, no matter how expert they are in their own field or domain, no matter how brilliant and intelligent they are, no matter how experienced in life they are. None of that matters if the ideas they come up with do not actually work in-market on their paying customers. And to really come to terms with that truth, takes copious amounts of humility — humility which is required to keep their egos in check. Since, coming up with a solution to a problem yourself (a.k.a have an idea) and demanding that people to do that, no questions asked, is actually a far easier thing to pull off. And feels pretty good too. Which is why our clients need to be very aware of their founder biases and how they can be so easily fooled.
Not only does humility have an important part to play here, but our Client also has to trust that the product development process (discovery) will weed out the weak ideas and discover and develop the strong ideas. Bringing certainty to what product actually works in-market, regardless of what the plan was thought to be.
In other words, they have to trust the product development process and their product team to enact this process, and hold them accountable to that executing that process honestly and rigorously. (not every time of course, but most of the time).
Because that product development process is the actual “engine of tech innovation” that focuses on making customer behaviors change. Which in turn creates actual product outcomes. And those product outcomes generate business outcomes that result in a viable, sustainable and stable business.
Prioritisation
So, what is the most effective prioritisation strategy, and rank order when it comes to deciding what to build in your tech product? Who’s needs should we put first?
#1 The Product — ultimately, you do what is best for the product, and defend its integrity from the inevitable generality and destruction of its potent business value, for the customers that value it the most, by not adding expensive, ineffective features that simply don’t deliver proven business results.
#2 Your Team — They are the ones who understand intimately what works and what does not work in the product, and they have learned that through hard fought contextualised experimentation. No one else could have that data and context. They are the ones that actually innovate in tech and test and validate. To do that, they need all the context from all the business stakeholders and customers of the product. The PdM is that conduit for them.
#3 Your End-Customers — They are the ones we ultimately learn from, about their problems, and what solutions work and what does not. However, we never expect them to tell us what they want or need, or what to build, and we don’t ask them either. If we gave them what they asked for our product would need to resolve all their problems in the world, and no such product should ever be built. Instead we listen to their struggles and pain and we innovate and test, and we measure what they do and don’t do.
#4 The Client — Some of their ideas can prove to be valuable, but their job is NOT to have ALL the right answers about the product and its customers, and then to dictate the product strategy. But rather, to trust and empower the product team to build the right product, and build it right, deriving a product strategy that actually works. For that is the only way the product will succeed in-market with real customers, and generate actual business results. A CEO must trust their people to do the right thing — not try to do it for them, that is simply too risky and ineffective.
Yes, yes, yes in our case, satisfying our Client’s needs is super important to us. They do indeed pay the bills, as do all tech founders whether they hire their own staff or outsource their core competencies. We keep our Client very close and engage them in the emerging product strategy and in the product development process. But they also know that this kind of business is not predictable and is complex, and the risks are largely unknowable, requiring: probe, sense and respond rather then sense, categorise and respond.
If you were one of our Clients, wouldn’t you rather be paying for a collaborative and highly motivated engine of innovation that has a known, predictable and reliable process for discovering a product that actually works in market, and that actually creates business results? Or would you rather gamble your business on a single smart person, or round table of experienced executives and consultants, to make all the right product decisions all the time? who are far removed from the real market and those doing the real innovation work in the product?
Then again, that might depend on what outcomes you want to create for your business…
