Strategic Product
Management
Principles

The value is always in the workflows. Always. This is why people make products nobody uses. They look at Jobs to Be Done at a tactical level, not at the outcome level. They miss the core job entirely. Think about it: why would I buy a hammer or a drill, if I can use a stone? Is not about the hole in the wall. Is about what I'm willing to pay for, and that comes down to three things: effort, time, and trust. You're selling the reliable delta between their current pain and the outcome you deliver.

Workflows, unlike frameworks, are dynamic. They guide what needs to be done to achieve a goal, not a recipe for success. Workflows allow for trust and auditing, and focus on the how we will achieve this practically, rather than theoretically.

Information leads decisions and not the other way around. Decisions should always be bottom up. Experts closest to the problem provide three options and one suggestion. Think of how AI works. It generates 3 options, with one (Recommended) answer. Experts should work like this.

Modern leaders are surrounded by services and tools that will happily think on their behalf. A McKinsey deck answers the strategy question. An agency designs the brand. An AI agent writes the report. A contractor builds the system. A board advisor frames the decision. All of this is healthy and necessary — no founder, no executive, no product leader scales by doing every piece of intellectual work themselves. The trap is that thinking and understanding feel like the same thing, and they are not. Thinking is the production of an output. Understanding is the internalised model of why that output is correct. The first is delegable. The second is not.

The failure mode is quiet and expensive. A leader nods along to a consultant's recommendation without ever testing it against their own model of the business — the model is gone, replaced by trust in the slide. A founder approves an AI-drafted strategy without rebuilding the argument from first principles — the argument is gone, replaced by the cadence of the prose. A product manager ships a roadmap an agency built without internalising the trade-offs — the trade-offs are gone, surfaced again only when something breaks and nobody on the team can explain why the original call was made. In every case, the deliverable shipped. The understanding did not.

The discipline is mechanical. When work comes back from anyone — agency, AI, advisor, analyst — read the output, then close it and rebuild the argument in your own words. Find the load-bearing assumptions. Stress-test the weakest one. If the conclusion still holds, you understand it; ship it. If it does not hold, you have just discovered something the original thinker missed, and your judgement is now stronger than theirs. Either outcome is a win. Skipping this step is how organisations slowly lose the ability to think for themselves while still appearing busy.

This applies with particular force to AI. Language models will produce confident, fluent, plausible reasoning on any topic. The quality of the prose is uncorrelated with the quality of the argument. Treat AI output the way a senior leader treats a junior analyst's first draft: useful, fast, occasionally brilliant, never trusted on its own. The leader who reads the AI output and ships it has not used AI to scale their thinking. They have used AI to replace it.

This concept is borrowed from M&A. There is a massive difference between strategic value and fair market value. Fair market value asks: "What is this worth today, to anyone?" Strategic value asks: "What does this unlock for us, given what we're building?" Strategic value is the assessment and acquisition of positions which create a flywheel of growth via positive feedback loops. Each win enables the next win. Most companies evaluate everything at a greedy fair market value measured in immediate cost and revenue. They miss the positions and externalities that compound tomorrow.

Effectiveness comes always before efficiency. The plane should fly first, then be optimized. A plane doesn't sell engineering. It sells reliability and trust. Efficiency is measurable and visible but turns systems fragile. Effectiveness is harder to quantify and often looks like waste but is agile. Balance, and knowing when to stop is key.

This needs to change. Diminishing returns dictates the reallocation of resources, not percentage growth. Every product, feature, and market follows an S curve. The question is not "Is this still growing?" The question is "Would this same investment produce more if allocated elsewhere?" Initiatives are bets, which need to be assessed in terms of one question:

Is it worth continuing the current work or investing the same time and resources in something new?

THESE ARE THE OPTIONS TO COMPARE AGAINST

Freedom to perform your functions without micromanagement is not free. It leads to complacency if there is no culture of ownership beneath it. People need to be responsible for their own targets. But they should never be punished for failed decisions they made while genuinely attempting to achieve them. That's how you kill initiative. That's how you train an organization to hide problems instead of solving them.

This can only work when the chain of command operates on trust. The manager is responsible for quality controlling the employee's output and workflows. At the same time, the manager does not punish the employee for making them look bad. The balls stop with the manager. That's the deal. You give people freedom, they give you ownership. You protect them from blame, they protect you from surprises.

See it. Say it. Fix it. If you see a problem, you own it, create alternatives and suggestions, and then escalate it. You don't wait for someone above you to notice or assign it.

Nobody is looking over your shoulder. If you remote work, you use your time to hit your targets. Everyone has to trust everyone to do the job they committed to do, at the level they needed to do it; or most of the organisation's time and resources is wasted in auditing if work is being done.

Most teams flatten Jobs to Be Done into a single layer. "The user wants to upload a file." That's not a job. That's a task inside a job inside a larger aspiration. JTBD is fractal. Every job contains sub-jobs, and every sub-job serves a parent job, all the way up to the life outcome the person is actually trying to achieve. If you only look at the task level, you build features. If you look at the outcome level, you build products people can't live without.

The hierarchy runs in three layers. At the top: the Aspiration — the life-level outcome the person wants. Below that: the Core Job — the functional progress they need to make. Below that: the Tasks — the specific actions that serve the core job. Most products compete at the task layer and wonder why they're commoditised. The ones that win understand the aspiration and work backwards.

The tree flows one way. The aspiration defines the objective. The objective is measured by key results. The key results are driven by KPIs attached to the tasks. If a KPI doesn't trace back up the tree to the aspiration, it's measuring activity, not progress. Kill it. Every metric earns its place by connecting to the job the person hired you to do.

Most product teams run discovery like defence attorneys. They start with a conclusion and build a case around it. The feature is already decided. The research exists to confirm it. The A/B test is designed to pass. This is not discovery. This is theatre.

Real discovery works like a homicide investigation. You start at the scene. You collect every piece of evidence before forming a theory. You interview witnesses without leading them. You let the data point you to the suspect — you don't pick the suspect and then go looking for evidence. When new data contradicts your working theory, you update the theory. You don't bury the evidence.

The order matters. Scene, collect, pattern, theory, test. Not theory, test, declare victory. The discipline is in step three: you look at what the evidence tells you before you form the theory. Most teams skip straight from scene to theory because it feels faster. It is faster. It's also how you ship the wrong thing with high confidence.

A team that leads with data doesn't move slower. It moves fewer times. Every decision costs resources. A wrong decision costs twice: once to build, once to undo. Data-led teams make fewer moves and land more of them. That's not caution. That's precision. And precision compounds.

Jeff Wilke told Bezos something that changed how Amazon operated: "You have enough ideas to destroy Amazon." Every idea a leader releases creates a backlog of work in process. If the organisation can't absorb it, the idea doesn't add value. It adds distraction. It stacks up. It competes with the last three ideas that also haven't shipped. The team isn't slow. The leader is flooding the system.

This principle has two sides. The first is restraint: not every idea should be released the moment it's conceived. Keep lists. Prioritise ruthlessly. Hold ideas until the organisation has the bandwidth to execute them properly. An idea released too early dies in the queue. An idea released at the right moment lands with momentum.

The second side is building the organisation to accept more. That's not about hiring more people. It's about executive bandwidth. The right senior team, with real autonomy, with clear domains, can run multiple ideas in parallel without collision. You're not increasing headcount. You're increasing throughput per unit of leadership. More ideas per unit of time, without the chaos.

The model is simple. Control the rate of release. Build the capacity to absorb. The bottleneck is never ideas. The bottleneck is always the organisation's ability to execute them without breaking what's already working. Protect the current operation. Then expand the aperture. That's how you stay inventive and operationally effective at the same time.

Most organisations draw their hierarchy with the CEO at the top and the frontline at the bottom. That's the org chart. It's not how value flows. Value is created at the frontline. The person writing code, talking to the customer, designing the interface, closing the deal. Everyone above them in the hierarchy exists for one purpose: to make those people more effective. The moment management starts serving itself instead of the frontline, the organisation is working upside down.

Jobs understood this instinctively. His philosophy was to hire people smarter than him and then get out of their way. Not because he was modest. Because he understood where value is generated. "We hire smart people so they can tell us what to do." The role of management isn't to direct. It's to unblock, resource, shield, and clarify. Management is a service function. The frontline is the product.

This is not servant leadership as a motivational poster. It's an operating model. The question every manager should ask is not "What do I need from my team?" but "What does my team need from me to deliver?" That's the inversion. I don't prioritise work. I prioritise unblocking.

Be run by ideas, not hierarchy. The best ideas have to win, regardless of where they come from in the org chart. When a junior engineer has a better answer than the VP, the junior engineer's answer ships. That's not democracy. That's meritocracy of ideas. And it's the only system that keeps A-players from leaving.

Speed isn't about rushing. It's about removing everything that doesn't need to exist. Every component you eliminate is one less thing that can break. Every approval layer you remove is one less bottleneck. Every process you kill is bandwidth returned to the people doing the work.

The loop only accelerates if the output of each cycle can be checked. If it can be evaluated, it can be automated. That is the gating function for everything in this section. A workflow with a clear, verifiable output can be handed to a machine, an agent, or a script and run a thousand times a day with confidence.

Momentum compounds. A team that ships fast builds confidence, attracts talent, and creates cultural intensity. A team that moves slowly breeds doubt, loses its best people, and trains the organisation that nothing urgent ever actually is. Speed is not the opposite of quality. Slowness is.

Most meetings fail because they confuse discussion with decision. People arrive without knowing what they're deciding, talk until the calendar runs out, and leave with action items that quietly become next week's meeting. The fix isn't more preparation or fewer attendees. It's a tighter loop, run on a clock.

The loop has four steps, in order. Observe — name the situation and the decision you're here to make in one sentence. Orient — surface only the information that changes the decision. Decide — pick the path with the orientation in hand, even if the data is incomplete. Act — assign one owner, one deadline, one success signal, before the meeting ends.

BORROWED FROM BOYD'S OODA LOOP. APPLIED TO MEETINGS.

The timebox is what makes the loop work. Set the window before the meeting starts — fifteen minutes, thirty, an hour — and treat it as a hard constraint, not a target. The window forces the room to bring the right inputs. Perfect information is not on the table; the best decision available inside the window is.

Headcount is not capability. A team of five A-players will produce more, faster, and at higher quality than a team of twenty B-players. This isn't motivational thinking. It's structural. Every additional person adds coordination cost. Every average hire lowers the bar that the team calibrates to.

High standards are not optional. They are structural advantages. When everyone around you is operating at an exceptional level, mediocrity becomes uncomfortable. It self-selects out. You don't need to manage it out. The culture does it for you. That only works if you refuse to compromise on who you bring in.

Every dependency you don't control is a decision someone else makes for you. When you own the stack — the product, the data, the distribution, the infrastructure — you can make decisions that companies with fragmented supply chains cannot. You can move faster because you don't need permission. You can cut costs because you see the full picture. You can make bold bets because you control the variables.

Fragmented supply chains create hidden fragility. You think you've de-risked by outsourcing a component, but you've actually handed a strategic chokepoint to a third party whose incentives don't align with yours.

Every enterprise software transformation sits on the same seven-layer stack, whether the architecture diagram exists or not. Data is created in the source systems, stored, made compute-accessible, given business meaning, reasoned over, acted upon, and governed end to end. The job of the stack is not to be technically elegant. The job of the stack is to deliver a defined business value end to end.

Three scenarios surface the same problem differently. Greenfield builds tend to over-engineer the lower layers and under-design the upper ones. Migrations tend to lift and shift the technical artefacts and quietly drop the business definitions in the move. Overhauls tend to fix one layer in isolation without touching the layers above and below. The pattern is the same in all three: the stack got built, the value did not arrive.

People work harder when they believe they are building the future. Not marginally harder. Categorically harder. The difference between a team executing on a roadmap and a team executing on a mission is the difference between compliance and conviction. Compensation gets people through the door. Mission gets them through the wall.

Build for a ten-year horizon, not the next press cycle. Short-term volatility is irrelevant if the long-term thesis is intact. Compounding innovation requires patience. Endurance is a competitive moat. Most competitors will quit, pivot, or get acquired before the hard problem is solved. The teams that stay on the problem long enough to solve it don't just win the market. They define it.

Leaders set intensity through personal example. Urgency at the top cascades through the organisation. High effort does not guarantee success, but low effort guarantees mediocrity. Extraordinary companies are built by people willing to endure extraordinary pressure. Not because they're forced to. Because the mission makes the pressure feel worth it. That's the test. If the mission isn't strong enough to make the hard days feel meaningful, the mission isn't strong enough.