feedback loop

The Product Manager’s great feedback loop in the sky

Reading a product management blog recently I came across this: “Corporate Product Manager have it easy because they don’t need to achieve Product Market fit.”

I interpret what the author was trying to say was: “corporate product managers don’t have to sell their products so they don’t have to work at making their product meet market needs and produce something customers to pay.” While there is a point there I think the author vastly under appreciates the difficulties faced by corporate product managers specifically because they don’t have the giant feedback loop in the sky provided by sales.

Other way round

The logic is the other way around: “corporate product managers have to work harder because they can’t judge success by market fit.”

When your goal is to create a product that earns revenue you have a massive advantage: you know what success looks likes, people buy. There is an default answer to the question “What is this product for?” – “To make money.” That might not always be the true but it is a good starting point.

As a Silicon Valley Product Manager you have one overriding goal loop: to make customer give you their money.

Money is the best form of feedback

When someone pays they giving you feedback. They are saying “The most valuable use of this money for is your product.”

They are choosing not to spend money on something else – perhaps a competitor or maybe something you don’t see as a competitor. They are giving up the interest benefits of money in the bank. Rather than buy your software a customer might decide to go to the cinema and see a film with the same money. Money is meaningful feedback, money costs.

Silicon Valley Product Manager can test almost any product hypothesis with the question: does it generate more revenue? Money is the great feedback loop in the sky.

Vanity products

In the corporate environment things are a lot harder. Unfortunately, corporates have a habit of starting vanity products, or continuing endeavours past the point where they should be killed.

I once managed a corporate extranet. The company had persuaded itself that customers really wanted to self-serve in all sorts of ways and had build a website to do just that. Umm.

When I took over the product I started meeting customers – actual customers who paid for the firms telecoms products. They were being given the extranet free to make the products more sticky.

It only took a few interviews to discover that customers did not want the knowledge sharing platform the website was intended to be. Quite the opposite. The last thing customers wanted was their engineers sharing information with engineers from competitors.

Bang went the big motivator for the website.

The remaining capabilities could be provided by the SalesForce system the company was in the process adopting. And it would be a lot cheaper to just give customers a styled SalesForce portal.

Kill your darlings

Inside the company the extranet was always fighting for resources because it didn’t deliver revenue. It repeatedly lost out to other projects that could claim increased product sales.

As Product Manager the way to deliver the most value was to kill the product. I did.

Corporations have a habit of treating every ideas a potential feature, without the discipline of market feedback choosing decisions come down to opinions.

Recently I inherited a backlog along with the product. It contained a multitude of stories that some stakeholder or other thought the system should do. Many more stories originated with team members who thought “It would be good if they system does this.”

If this were commercial product I could reason, and even test, whether those stories held value: would anyone be willing to buy them? What new market could they open up? Can they give us an advantage over a competitor?

But no. There is no feedback loop. No market discipline. Everyone of those stories is there because some stakeholder thought it was a good idea. Stakeholders don’t agree – one say it is pointless, another that it is essential. Some stakeholder have command more authority than others – little Hippos.

Data over opinions

As Jim Barksdale at Netscape said: “Data beats opinions – If you don’t have any facts, we’ll just use my opinion.” Everyone of those stakeholders has an opinion and without the money feedback loop getting data can be impossible.

Part of my role as Product Manager is to determine the value and make judgements on those opinions. As a result I spend a lot of time talking, or rather listening, to stakeholders. I have to be fair (or at least seen to be.)

I work hard at trying to determine the value of my product and understand how enhancements can add value. But that also means I need to decide what constitutes value because it is not money. No wonder many product people get exhausted and give up trying.

Less is more but doing less means saying no. That can be career threatening. It also means deciding what to do soon and what to delay, again without the giant feedback loop in the sky that can be hard.

Corporate life isn’t easy

So when I read a comment like “Corporate Product Manager have it easy because they don’t need to achieve Product Market fit” I get annoyed. This is another example of the Silicon Valley view of Product Management dominating the discussion.

Corporate product management might look easy from the outside but from the inside I long for a giant feedback loop in the sky to give me the data.

The Product Manager’s great feedback loop in the sky Read More »

Lets talk about money: the ultimate feedback loop

Pile of dollars

Money is information. I like to joke: “money is the best form of feedback.” Unlike comments in a retrospective, kudos cards, and SurveyMonkey results I can trade your information for something else and in so doing, give someone else feedback.

When someone buys your product they are saying “Your product is worth giving up …” – money in the bank, a nice meal out, a new car. You give them the product and they give you information. Money is a feedback, perhaps the ultimate feedback loop.

Within companies money also provides information. Money signals what the company values and who has power.

I worked as an agile coach with a Belgian company applying “the Spotify model” a little while ago. The leader of the tribe repeatedly told squads “you are masters of your own destiny.” He was keen, at least when speaking, on self-organisation, on squads taking control and aiming high.

One of the squads I coached decided the best way of improving performance was to improve quality: reduce bugs, reduce outages, make customers happier, improve code quality, etc. Then they asked for money for technical training and coaching. End of story.

The squad had no budget of its own. The tribe had budget but it was earmarked for something else. Asking for more budget was off the table. The squad only had power while they didn’t spend any money.

Team finances

Teams, development teams specifically, rarely get to see or talk about their own budget. In fact they rarely get to talk about money at all. It is funny, most of us live and work in capitalist in free markets societies. Success is judged by profit (or at least revenue), and the aim of the company is to make money for investors.

But day-to-day how much does anyone on your team know about the finances of your team? How much does your team cost per month?

What about your product: What does it sell for? What is the profit margin on the product? How much will that new feature you are adding earn?

While managers will often talk about cost-benefit “bang for your buck” and ask “how long will feature X take?” or “is it a quick win?” it is seldom quantified. If it is then it is probably only in days or weeks not pounds, shillings and pence.

Inside the company it is almost as if we live in a cashless communist enclave where money can’t be spoken of. People even say “Its all about money” as an insult – still they expect to be paid in money and (usually) want the company to keep doing so.

Informed authority

But what is devolved authority, self-determination, self-organization if it isn’t backed-up with the power to spend money?

How are we to make informed decisions if we don’t know how those decisions will effect cashflow? – while we might know costs how can we begin to talk about revenue without information. And how can we evaluate the impact of our decisions if we don’t see the bottom line?

I give my children a few pounds a week pocket money. They can choose to save it or spend it, I do my best to respect their choices even when I disagree. When it comes to bigger things, holidays and even clothes, Mum and Dad make the decisions.

If companies don’t open up finances to teams then they don’t trust those teams. They are placing severe limits on what the teams are allowed to self-organize. But in almost every company I’ve ever worked for, or with, development teams are treated like children and kept away form money. Even asking about money is frowned on.

Is it any wonder engineering decisions happen without reference to financial impacts? Why should we expect engineers to suddenly become aware of the cost of their decisions when actual costs are hidden? And there is no feedback loop?

Hourly efficiency

I can’t recall ever seeing a team with their own budget. Even a small budget would be an improvement (of course ultimately we want Beyond Budgeting but I’ll settle for imperfect budgets right now.)

I’ve long advocated Kazuo Inamori’s Amoeba management model. Inamori points out that in most companies teams get no feedback on their financial performance. In amoeba management, hourly efficiency reports are used to control costs and allow teams to make their own trade-offs on expenditure – not unlike beyond budgeting in fact. (In Kyocera hourly efficiency is calculated as: (revenue – (costs – wages))/hours.)

Unless teams have financial information they can’t make decisions. Back in Belgium I couldn’t quantify the cost of bugs because there was no data on salaries, contract rates, product contracts, support desk costs. I couldn’t put a value on removing bugs. But I was forced to put a cost eliminate those bugs. Consequently I couldn’t do the cost benefit equation and it was down to one man making a decision which seemed to favour some teams over others.

Talking of value without financial feedback loops is pointless.


Enjoyed this post? Subscribe for updates and download Continuous Digital for free

Lets talk about money: the ultimate feedback loop Read More »