The Product Mindset

Some work is very clearly product work. It’s work on things where the success and failure is dependent on the users of the thing. Your users pay you. Their satisfaction matters above all else.

Optimizing for the satisfaction of end users is a distinct activity. Hypotheses have to be assessed and then tested – because it’s very likely that you’re going to be wrong. There’s technology that has to be set up such that it’s reliable and robust for the intermediate to long run. It’s designed to be effective and persistent, with all of the instrumentation that goes along with that. That might include manual A/B testing, user-focused analytics, and extra special attention on the optimization objective.

Clear product work is quite a bit different from other types of work. It’s distinct.

For instance:

Consider a basic CRUD (Create, Read, Update, Delete) startup. Let’s make it a single sided business model, pure SaaS. You’re arbitraging value, nothing more, nothing less.

So, assume that you’re the CEO of that firm. Assume that somebody really likes purple. So they want to change the product to purple. No other real reason than they like purple and want to see themselves reflected in the product. The best response you can give is “test it”. As the CEO, you don’t actually know if purple will make it easier to attract customers. You don’t know if it makes it easier to convert. If it’ll increase use of the product. If it has a positive impact on churn and increases Life Time Value (LTV).

You may have experience and judgement. It may be the case that, in your brandkey, you’re not a fun brand. You may not, personally, prefer that the whole site gets a purple wash. But you don’t actually know, because you have no data, about the impact of purple on any of things your users value.

The right answer, “I don’t know, let’s run a test”, preserves the creativity and face of the person proposing the idea, and opens up the business to the possibility that it’ll be effective.

A CEO that is aligned with the users is more likely to point true north than one that isn’t.

Faster Horse

Import(“If I had asked people what they wanted, they would have said faster horses“);

Ford demonstrated that horseless carriages were better than horses, so he won the 20th century. The evidence of the superiority was demonstrated by customer demand.

Import(“never again to invent something unless it was commercially marketable”);

Edison invented an electronic voting system for the New York State Senate. The voting system was superior. But it didn’t allow enough time for bribes to be paid. In response to the failure of that product, he adopted the commercial rule.

Better isn’t always evident, and not always wanted. It might not actually be enough for a CEO to create value. If the market isn’t with you, if they haven’t bought into your vision, then it isn’t going to get anywhere.

The product as a hypothesis

Deep down inside the founders heart, there is the conviction that the hypothesis will work out. That the value generated by the startup will be persuasive and effective. You want it to be true. Often desperately.

The opposite of what you want to do is hide a product away from everybody until you reckon that it’s absolutely perfect. The sooner you can get data, the better. But many CEO’s don’t seem to handle market feedback well. They fail silently for months. There’s a kind of fear of embarrassment that goes with it.

Import(“Colin Powell 40/70 Rule”);

If you wait for all the data to come in before killing a startup, you’ll have done everybody a huge disservice. If you don’t wait long enough for all the data to come in, then you’ve killed it too early. Waiting for about 40% to 70% of the data to come in is a really good rule of thumb.

In effect, the whole startup is a hypothesis. It’s expensive and troubling to run a startup right into the ground with 100% of the data in. Hanging on for too long is a problem. Quitting too early is a problem.

When push comes to shove, the CEO is going to defend the users, because the users are the ones paying the bills and justifying the existence of the firm.

The Services Mindset

When you’re running a PS shop, you’re paid by the client. And sometimes, often maybe, the client isn’t advocating for the user.

That extra chain in the relationship flavors the work.

At the crux of it is whether or not the client is an effective advocate for the user.

Some agencies will use research to assist the client in being an effective advocate for their users. A good question is whether or not the client has the integrity to stand by what the users are indicating, and, more often than not, the courage to tell their bosses about it.

The effectiveness of the PS shop for the users is moderated by the quality of the client stakeholder. And I admit I had several extremely effective client stakeholders over the years. But that’s a risky variable.

The revenue for the PS shop comes from the client, not the user. So the satisfaction that matters, that needs to be optimized, is the stakeholder.

In general, it’s far easier to optimize the satisfaction of a single client stakeholder than it is for an entire market.

The client is stimulated to produce data. The PS firm synthesizes that data. The client is stimulated to produce new data. Several cycles can be executed in a single hour. You can watch your primary customer respond to what you’re saying as you are saying it. Very effective. Almost like writing code and reading compiler errors.

It’s not trivial to run a PS shop. It’s hard work. But there’s comparatively far less risk. You’re meeting customers directly where they’re at.

There’s an art that’s involved in any service industry. But more often than not, the agency president isn’t going to tell the client that they’re ineffective at advocating for the user, especially if it’s going to jeopardize a revenue stream. And, in particular, when the agency president doesn’t have any data to back that assertion up.

When push comes to shove, where it really matters, the revenue stream is to be protected.

It’s an entirely different mindset.

The Product Mindset

A Canadian would want to integrate them both.

I don’t they’re compatible.

Goal structures are hierarchies, not networks. Incentive alignment is vital to achieve any sort of sustainable arrangement.

A stance is one way or another. You can try to have it both ways, but that’s incredibly sub-optimal.