People · Product · Process. A requested fix needs a diagnosis before the customer's budget is committed.

A metal-art business wanted advertising that looked more like its competitor's. The competitor put its founder in front of the camera. My client sold personalised pieces, and copying that advertising would have meant making a creative decision before we had answered a more useful question: who was buying the art, and what were they buying it for?

That distinction is where I start People Product Process. A requested deliverable gives you a possible action. The customer's problem gives you a reason to take it. I want evidence for the reason before I commit the budget, build the automation or write the campaign.

An owner asking for a website might need a clearer way to explain an offer. They might already have a clear offer and a checkout that fails. They might have neither problem. A new website can be relevant to each situation, but the scope, the evidence and the next decision will be different. Treating the request as the diagnosis skips the work that distinguishes them.

People Product Process organises that work into three phases. Each phase contains three stages, and each stage supplies something the later work needs. The order matters because the message, offer and delivery should describe the same customer and the same promised change.

The phases answer different questions about that agreement.

Each stage needs something the earlier work established

The People phase starts with a problem that exists independently of anything I sell. A fence supplier can describe a missing fence. A homeowner can describe a dog escaping into the road. The second description allows several possible responses and gives you something to investigate. The first already contains the supplier's preferred answer.

The future then describes what a better situation would look like. The dog stays safely in the yard. The owner can use the yard without constantly checking the gate. A fence specification becomes useful once it can be evaluated against those conditions, including whether a fence would address how the dog gets out.

Transformation names the work between those states. It includes the installation, but it might also include maintaining a latch, changing an access routine or obtaining permission to modify a boundary. Those are examples of things to check, not details we know about a particular homeowner. A sale that ignores a necessary change can leave both parties arguing over an otherwise well-made deliverable.

The Product phase uses that diagnosis. Benefits connect the work to consequences the buyer values. Message expresses those consequences in language the buyer recognises. Offer puts the scope, deliverables, responsibilities, price and acceptance conditions into an agreement.

The Process phase makes the agreement usable. Qualification establishes whether the buyer and supplier can fulfil their respective parts. Sales gives the buyer enough relevant information to make a decision and a clear next step. Fulfilment delivers the value and provides evidence that the agreed conditions were met.

The dependency runs across phases as well as down the list. Customer language gathered during diagnosis supplies the message. The future supplies the outcome the offer describes. Required changes supply the qualification criteria. Delivery supplies evidence for the next conversation about results.

A missing input can be hidden by competent execution. A writer can produce a polished page without talking to a customer. An engineer can automate a follow-up sequence without knowing whether the offer fits. The page and the automation may work exactly as specified while the commercial assumption underneath them remains untested.

Diagnosis gives the team a decision to make

I use the framework to separate those assumptions. A weak conversion rate invites questions about the audience, the proposition and the buying path. It doesn't identify which one caused the result. A new CRM might help a team that loses qualified enquiries. It won't by itself establish why anyone should enquire.

This also changes how I think about a process problem. The order of diagnosis doesn't mean delivery capacity can wait until after a campaign launches. A capacity limit discovered at the end can change the offer at the beginning. The stages give you a way to trace that dependency and revise the agreement before making promises the operation can't keep.

The work needs to leave something another person can inspect. A problem statement should identify the situation and its consequence. A future description should identify the observable improvement. Change commitments should identify who has to do what. These documents can be plain. Their value is that somebody can disagree with them before the disagreement becomes a project failure.

The same discipline applies to evidence. A customer's explanation is useful testimony, an account export records particular events, and a case study records what happened in a different situation. They answer different questions. Combining them doesn't remove their limits.

The metal-art request became useful when it led us to examine who bought, which messages they responded to and how we had divided the advertising data. The proposed creative was a hypothesis we could test against those findings. That's the kind of decision this framework is meant to support. It gives the team a way to choose its work and discover when the initial choice was wrong.

A method can organise the work without guaranteeing the result[summarize]

The sales idea behind this method is to sell a future the customer values. Michael Killen's Sell Futures, Not Features is an influence on that framing. The distinction between what a supplier does and what the customer receives runs through the stages. An offer, a message or a qualification question earns its place by helping that customer reach a defined result.

I use People Product Process as an arrangement of practical questions. Its usefulness depends on what those questions uncover and what the team does with the answers. A name for a framework doesn't establish that its diagnosis is correct, and a complete set of documents doesn't establish that a market will buy.

My own record contains both successes and failures in the same broad markets. I have sold metal art successfully, and I've also worked on a garden-art campaign that never found a profitable route through paid advertising. The products attracted attention. That didn't settle whether the people clicking would buy at a price that supported the business.

My account of that unsuccessful campaign still contains uncertainty about the cause. The website was weak. The budget limited what we could test. Purchase intent might also have been weaker than the engagement suggested. I still can't identify one cause with confidence.

A guarantee has to describe something the supplier controls

I can commit to the work I'll do, the outputs I'll deliver and the process for deciding what the evidence means. I can't guarantee that every product will sell profitably or that another business will repeat a past customer's growth.

That boundary affects the offer. A testing engagement can specify the budget, the hypotheses, the work to be completed, the records to be returned and the decision the findings should support. A software engagement can specify what an operator must be able to do and what evidence demonstrates that it works. A remedy can hold the supplier accountable for failing those commitments.

A promise of future revenue reaches beyond those outputs. Customer demand, the buyer's operation, competitors and the conditions under which the product is sold also affect the result. Better diagnosis can reveal risks and improve decisions. It doesn't put all of those causes under my control.

The case figures in this article come from my accounts of the work. They describe particular engagements, including what I remember about their limits. They aren't independent audits or experiments that isolate the contribution of each change. A useful case tells you what to investigate in your own situation. It doesn't remove the need to investigate it.

The decision determines how much diagnosis is needed

The stages also don't need equal amounts of work. A known customer asking for a well-understood change may need a brief confirmation of the problem and future, followed by careful scope and acceptance work. An unfamiliar market may need substantial research before an offer is responsible.

The distinction should be explicit. A light pass means the team knows which assumption it's relying on, why the existing evidence is adequate and what finding would reopen it. Skipping diagnosis means the assumption never became visible.

You can use the framework without hiring anyone to run it. Start with a real decision, such as whether to change an offer or invest in a new channel. Write down the evidence you have, the consequence you want to change and the uncertainty that could alter your decision. The stages then help you work out what's missing.

The first question is whether the thing described as the problem is the cause, a symptom or simply the deliverable someone has already decided to buy.

Stage 1 separates the complaint from its cause[summarize]

The problem exists whether I'm there to solve it or not. That's the constraint I put on the first stage. A description that only makes sense because I sell advertising, websites or AI systems needs more work.

An enquiry for more leads gives me a starting point. I need to know what the business calls a lead, which leads become customers, what those customers are worth and where the operation currently fails to turn interest into a useful relationship. More enquiries can help one business and overwhelm another. The request alone can't distinguish them.

The same applies to a request for automation. A person might be repeating a necessary task by hand. They might be repeating a task nobody needs. They might be compensating for inconsistent inputs that an automated system would process just as inconsistently. Each possibility needs a different response.

Past failures can explain present constraints

I start by asking where the business has been hurt before and how that history affects current decisions. Its practical subject is a rule or restriction whose reason needs to be understood.

A previous failure may explain why an owner now reviews every change, refuses a channel or keeps an important task away from the team. The history might justify that restriction. It might also mean the business is applying an old response to a new situation. I need the account of what happened before I can judge which.

The questions in my diagnostic notes are deliberately specific. Where is money being wasted? Who deals with the consequences when something breaks? Which recurring email creates a problem the team can't resolve? What happens if the business leaves the situation unchanged?

The wording can be direct without making the person defend their character. Asking who handles a failed order can identify the real work, the escalation path and the information that person lacks. Calling the owner controlling doesn't establish any of those facts.

I also look for someone working extraordinarily hard to compensate for a workflow that doesn't reliably work. My notes call that Heroic Failure. An owner personally correcting every order might be keeping customers satisfied. The diagnosis needs to explain why that intervention is necessary and what would happen without it.

The intervention is evidence of a dependency. It doesn't prove that the team is incapable or that the owner is unwilling to delegate. Missing information, unclear authority, inconsistent standards or inadequate capacity are all possibilities to investigate. Replacing the person before understanding that dependency can reproduce the failure with a different name on it.

Repeated why questions need evidence at each step

My habit of going seven layers deep is a prompt to investigate beyond the first answer. It isn't a requirement to extract seven confessions from a customer. Some problems have a direct, well-supported cause. Others have several interacting causes, and forcing them into a single chain would make the diagnosis worse.

Consider an illustrative enquiry about advertising costs. An owner asks for more sales. The team explains that acquiring a customer costs too much. That leads to questions about how acquisition cost is calculated, which customers are included and what happens after an enquiry arrives.

The next answer might point to an audience mismatch. It might point to a sales follow-up failure or a product that produces too little margin. Those answers should send you to records that can distinguish them. A spreadsheet showing spend alone can't establish why customers failed to buy.

The discussion can also uncover an operational barrier to finding out. Perhaps the team doesn't reconcile the account data with orders. Perhaps nobody owns that reconciliation. Perhaps a previous report was unreliable. The resulting project might include a reporting change before a campaign change makes sense.

A person's reluctance to look at a number is a possibility to discuss with them, not a hidden motive the consultant gets to declare. The further an explanation moves from observable work into somebody's beliefs, the more carefully I want to separate what they said from what I inferred.

A useful diagnosis records both. It might say that the owner reports distrusting the dashboard and that order totals haven't been reconciled with it. The first claim has a witness. The second can be checked. Declaring that fear of what the numbers show caused the business's trouble would require evidence those observations don't supply.

The problem statement preserves the uncertainty that matters

The output is a written problem statement that another supplier could use. It should explain the current condition, the consequence and the evidence, without requiring the reader to agree to my preferred solution.

A practical statement needs to answer a small set of questions:

• What's happening, to whom and in which part of the work?
• What consequence makes it worth addressing?
• What records or direct accounts support that description?
• Which possible cause remains uncertain?
• What decision needs to be made next?

The familiar shape in my notes is a current process or belief causing a specific pain, with a consequence if it remains unchanged. The shape is useful because it forces a relationship between the condition and the consequence. That relationship still needs checking. Putting a causal verb in a sentence doesn't prove causation.

The statement can be provisional. A team can know that paid enquiries are expensive and still be unsure whether the constraint is targeting, follow-up or margin. A responsible next step is then a bounded investigation. A confident statement naming the wrong cause would be less useful.

I want the consequence stated at its real strength too. A preference for nicer reports doesn't become a threat to the business because a consultant needs a persuasive proposal. A known contractual or operational consequence belongs in the diagnosis. An imagined catastrophe doesn't.

The problem statement becomes a reference during the work. A proposed feature should be explainable in relation to it. A new finding can change it. A disagreement should be traceable to the evidence or assumption in dispute, rather than becoming an argument about whose preferred tactic gets funded.

The founder's account supplies essential context, but it's only part of the evidence. Customers, transactions and the people doing the work may describe a different problem. Stage 1 needs room for those accounts to change the conclusion.

Customer language and cohort data challenge the proposed fix[summarize]

A founder knows a great deal about a business. A founder still sees it from the supplier's side. Customer research lets me compare that account with what buyers describe and what they do.

My sources include discussions in relevant communities, comments under competitors' videos, reviews, support tickets and sales conversations. Each provides a different view. A support ticket describes somebody who already has the product. A review of a competitor may describe somebody my client could serve, but it could also describe a buyer with different requirements. A public comment can reveal vocabulary without establishing purchase intent.

I want those distinctions preserved while collecting the material. Otherwise a document full of customer language becomes a mixture of incompatible situations that happens to sound convincing.

Keep the words and the interpretation separate

My notes call the resulting collection a Lexicon of Pain. The useful part is a record of exact phrasing, the source it came from and the situation it describes. I can then distinguish the customer's words from the meaning I assigned to them.

A complaint about a slow dashboard might mean an occasional delay, a failed export or a report that arrives after a decision. Those are different problems. The surrounding account helps identify which one was meant. A clipped quotation can remove precisely the detail that would make the research useful.

I collect positive accounts and reasons for choosing alternatives as well as complaints. Negative reviews are useful for locating unmet expectations. They don't represent every buyer, and a five-star review doesn't become worthless because it's positive. The research question determines which sources I need and what bias each introduces.

Repeated language is worth examining. It can identify a shared concern and suggest a message to test. Repetition alone doesn't establish how common the concern is in the whole market. A community may attract people with the same problem, or several posts may be repeating one story. The source and the population still matter.

A workable collection should preserve enough information for another person to challenge the interpretation. I record where the words came from, whether the speaker was buying or using the product, what triggered the comment and which proposed claim it could support. A question or uncertain inference stays marked as one.

The collection should also include contradictions. Buyers who praise a feature and buyers who dislike it may have different use cases. Combining them into a single average persona can hide the distinction the offer needs to make. Research is useful when it changes a decision, including a decision about which buyers to serve.

Private support records and sales conversations need appropriate access and handling. The right to read a record for service delivery doesn't automatically create permission to publish it as a testimonial. A public quotation needs its own check, and an internal teaching document can often use a paraphrase without identifying the person.

The metal-art buyers pointed to a different message

The metal-art engagement gave me a concrete example of why that work matters. The business sold personalised wall art and was comparing its advertising with a competitor's founder-led creative. The proposed response was to make advertising that competed on the same presentation.

I exported the Facebook advertising data into CSV files. This was before I had learned to code, so the analysis happened in Google Sheets. I built macros, organised the exports and created calculations to compare the material we were running.

The cohorts included different creative and headline combinations. Looking across them let me examine which groups were valuable rather than treating the account as a single performance number. Women aged 45 and above stood out, and iPhone users also showed a lift in the account I described.

That finding gave us a more specific basis for the work. The product could be positioned around family, personalised names and making a house feel like a home. The campaign language included the family themes I recall as "Family is Forever" and "Make Your House a Home." My account of the campaign doesn't preserve every original word, so I wouldn't treat those recollections as a recovered archive of the ads.

We also separated campaigns by age and gender so we could make different budget and bid decisions. The message and the account structure changed together. The result wasn't a clean experiment in which a sentimental headline was the only changed variable.

The business grew from roughly $10,000 a month to about $150,000 a month over approximately 90 days. It shows why the research was commercially useful in that engagement. It doesn't prove that every family-oriented message will produce that growth, or that age and device identify the right audience for another store.

The buyer interpretation also needs the right level of certainty. The work supported gift-oriented positioning. It didn't give me direct access to every buyer's identity, private feelings or relationship with their family. A plausible account of why a grandmother buys a gift is a hypothesis unless that buyer actually told us.

Research needs a route into the work

The conclusion to carry into a new engagement is to test the proposed creative direction against evidence about actual buyers. Copying a successful competitor leaves open whether the two businesses attract the same customers, sell under the same conditions or can deliver the same promise.

The research output should therefore change something specific. It may narrow the audience, identify a message to test, reveal an objection the page doesn't answer or show that the requested feature addresses the wrong use case. A collection that can't inform any of those choices needs a clearer research question.

The language record and the purchase record can also disagree. People may describe one reason for buying while responding to an offer for another reason. An analysis should leave that discrepancy available for investigation. Choosing whichever source makes the preferred campaign easier to justify defeats the diagnosis.

The next stage uses what the evidence supports about the customer. It asks what would be observably different if the problem were solved, so the team has a destination against which to evaluate both the product and its advertising.

Stage 2 makes the desired future observable[summarize]

A goal names an improvement. A useful future description explains what that improvement allows a person to do. I want both, because a metric without a use can produce the wrong project, and a future without evidence can produce a promise nobody knows how to fulfil.

The roadside-assistance example in my notes makes the distinction easy to see. Imagine a driver stranded with a flat tyre. A technician's tools matter because they help get the driver moving safely again. A demonstration of the tools would answer a different question from the one that brought the driver there.

The same distinction applies to technical work. An owner may need a report before deciding where to spend. They don't necessarily need a tour of the data warehouse. The technical design still matters. It earns attention when it explains how the owner will get a trustworthy answer, what it will cover and what happens when the data is incomplete.

An ordinary day exposes missing requirements

I ask a customer to describe an ordinary day after the problem has been solved. My notes call this the Day in the Life test. The purpose is to move past a general aspiration and find the work that would be different.

A customer who wants more leads might describe a calendar with suitable prospects rather than a longer list of names to call. The next questions are what makes a prospect suitable, who checks that, how the call gets booked and what the team can handle. The future starts to imply requirements the original request left out.

I want to know what the person will see, what action they can take and which recurring intervention will no longer be necessary. A dashboard, an accepted application or a completed task can provide evidence. The evidence should correspond to the benefit the customer actually named.

An illustrative reporting future might be an account manager comparing campaign results without assembling exports by hand. That description still leaves important questions. Which campaigns? Which result? How current must the records be? Can the manager trace a total back to its source? Who handles an account that stops supplying data?

Those questions make the future more useful. They also stop a phrase such as "one source of truth" from concealing several incompatible requirements. A team can agree that a report looks good while disagreeing about what it means.

Feelings and status can matter without becoming invented measurements. A customer may describe wanting more control over their operation. I can ask what they would be able to decide or delegate that they can't decide or delegate now. I don't have to tell them what their anxiety means or promise to remove it.

The solar portfolio needed a shared view of the work

My solar experience included different engagements, and they shouldn't be combined into one larger story. One customer reached very high daily advertising spend. Separately, I consulted with an agency serving a portfolio of dozens of solar customers.

In that portfolio engagement, the customers were buying leads. The agency operated their advertising accounts, and the work needed to make performance across those accounts visible together. Individual account views didn't give the team an adequate way to compare where attention was needed.

I helped put together the data connections and the dashboard. The dashboard let the agency examine which clients were doing well and which weren't. That's a more specific future than "better data." People responsible for decisions could inspect the portfolio rather than depend on disconnected accounts and individual recollections.

The operating arrangement was also distinctive. The agency had a team of media buyers and a round-robin approach to tasks. Automations monitored for unusual results and generated work for the buyers. Tasks could be distributed across the team instead of making one person's availability the condition for an account receiving attention.

I want the future described as a working situation. A chart alone wouldn't explain how the work gets assigned. A task system alone wouldn't explain which performance change should trigger it. The useful result connects observation, decision and action, and leaves the team able to see what happened.

I was proud of that dashboard even though it was crude compared with the engineering work I learned later.

A proposal can make a future credible through its plan

The African crypto-radio project shows a different kind of future. The team wanted grant funding for a programme it could actually execute. I helped as a consultant with grant strategy, copy, CRM structure and responses to resistance. I wasn't leading the project, and the team did the work of winning the funding.

The proposal had a programming plan, collaborator information, budget detail, team responsibilities and operating procedures. Its CRM had public-facing and internal elements so the planned use of funds could be made visible. Those particulars gave the proposed programme an operational shape.

The team secured roughly $350,000. My account supports the work we did to make the plan and its accountability credible. It doesn't establish the private motives of every person who approved the grant, or prove that a different team could reproduce the decision by borrowing the wording.

The transferable practice is to describe the future in a way that lets a decision-maker inspect what has to happen. A programme with a schedule, responsibilities and a budget can be questioned in detail. An ambition to become influential leaves most of that work unresolved.

A future needs a boundary as well as a destination

Technical buyers may want a more uneventful operation. A pipeline should reject or isolate an invalid record according to its design, expose the failure and allow the responsible person to recover. That's a useful future to specify. "The system never breaks" is a different and much larger claim.

The same boundary applies to commercial work. A calendar of suitable calls depends on who responds, how the form qualifies them and whether the sales team follows through. The provider can own some of those tasks and the customer others. A future description should make the dependency visible before it becomes a disagreement about results.

I compare the future with the eventual scope. Each promised improvement needs a deliverable, an agreed customer responsibility or an explicitly unresolved dependency. Anything that has none of those is an unsupported part of the pitch.

This gives us a present situation and a desired situation, with evidence for each. It also starts to reveal the work between them. That work includes changes the customer will have to make, which is what Stage 3 brings into the agreement.

Stage 3 names what has to change[summarize]

A customer can agree with the diagnosis and like the future while being unable to do what reaching it requires. Stage 3 makes that difference explicit. The transformation is the set of changes in work, behaviour, resources and systems that connects the two states.

A new result can involve a new tool, but it can also require people to supply data differently, accept a testing budget, change who approves work or stop using an old workaround. A contract that only describes the tool leaves those obligations open.

The discussion should be concrete enough that both parties can tell what agreement would mean. "Be more data-driven" doesn't say who maintains a record or which decision will use it. "Provide the order data and reconcile the campaign totals before deciding the next allocation" identifies work someone can own.

Separate prerequisites from things the project will produce

Take a hypothetical reporting agent. The desired future is a report the team can use without manually rebuilding it. The current information lives in documents with inconsistent names, definitions and access permissions.

An agent might help retrieve and arrange that material. It won't decide on the organisation's behalf which conflicting figure is authoritative unless that decision has been defined and someone has the authority to make it. The project needs a rule for the conflict as well as a way to find the documents.

The required changes might include identifying the authoritative records, assigning an owner for updates and deciding what the report should do when an input is missing. Some of that can be part of the provider's work. Some requires the customer's participation or access approval. The offer needs to say which is which.

A prerequisite deserves a different treatment from a deliverable. Access to a system may be required before work starts. A cleaner schema may be something the project produces. A customer who can't provide the first hasn't necessarily failed a commitment to provide the second.

This is also where I want to expose the cost of adoption. A workflow can be technically correct and still require more effort than the team can sustain. The diagnosis should include the people expected to use it, the information they'll have and what happens when their normal work interrupts the new routine.

Testing requires permission to learn an unwelcome result

Commercial changes have the same dependency. A customer can want profitable acquisition while expecting every initial experiment to make money. Those are different commitments. A test needs a bounded budget, a question and a decision about what to do when the evidence is poor.

The budget should be an amount the business can responsibly risk. It should also be adequate for the intended question. A small test may help identify a problem or reject a particular approach without establishing that the whole market is viable. Expanding the conclusion because the customer needs certainty doesn't create better evidence.

My agency lead-generation work involved changing the buying path as well as the ads. A form asked prospects for enough information to qualify them before a sales conversation. Video campaigns also helped build and warm the audience before conversion campaigns asked for the next commitment.

That required the business to accept a different way of handling enquiries. A form can reduce immediate bookings while improving the suitability of the conversations that remain. The result needs to be assessed across the path, including cost, contact, qualification and sale. A single lead-count target can reward the old behaviour even after the form changes.

The customer's commitment is therefore about what will be measured and how the team will respond. If sales continues to reward every booking equally, qualification can become a rule everyone works around. If the ad system receives the wrong completion event, the new form may not supply the signal the team intended.

Beliefs, actions and systems need to support one another

My notes group the change into beliefs, actions and systems. I use those as prompts to check whether the agreement is coherent. They aren't quantities in a formula for revenue.

A belief can be an operating assumption, such as the view that any enquiry is worth a call. An action is what someone does because of that assumption. A system is the form, calendar, measurement or approval process that makes the action repeatable.

Changing only the system can leave people recreating the old behaviour outside it. Changing only the stated belief can leave the calendar and incentives rewarding exactly what they rewarded before. The questions help identify those conflicts before the provider calls the installation finished.

Technical scoping needs the same specificity. Agent Redwood is my framework for considering the components of an agentic system and deciding which deserve investment. It isn't an orchestration library or a piece of software that automatically supplies all the missing decisions. A scoping framework is useful when it exposes a choice about memory, tools, evaluation or integration that the team needs to make.

A customer asking to make an agent better needs to say what better means in the work. Does it need to produce a different answer, use an approved source, take an authorised action or make a failure visible? That answer is part of the transformation, because it changes both the design and the proof of delivery.

A change commitment can make the engagement unsuitable

I want the required changes recorded with an owner and a way to observe whether they happened. The list becomes part of qualification later. A missing access permission, an unfunded dependency or an unwillingness to define acceptance can be a reason to narrow or decline the work.

The reason should be stated without turning it into a judgment about ambition. A business can have a worthwhile problem and still be unable to fund the proposed approach. A person can want a future and reasonably reject the changes this particular supplier requires.

I'd rather discover that mismatch before signing. The alternative is an engagement in which the supplier expects changed behaviour, the customer expects a self-contained deliverable and both believe the other party has changed the deal.

The People phase is finished when the problem, future and required changes are clear enough to support a decision. The Product phase then asks what value the proposed work creates and how to explain that value without promising more than the agreement can deliver.

Stage 4 follows each feature to a useful consequence[summarize]

A feature describes something the product or service has or does. A benefit describes why that property matters to the customer. The relationship needs explaining, especially when the supplier understands a technical detail that the buyer has no reason to care about on its own.

I use the question "So what?" to work through that relationship. The first answer often restates the feature in slightly plainer language. Another question can move the explanation into the customer's work. The stopping point is a useful consequence I can substantiate, not the most dramatic feeling I can attach to it.

A Python library name is a feature of my delivery. It might be important to a technical buyer reviewing maintainability. The person paying for the operation may need to know which failure the design detects, who can see it and what work is required to recover.

Follow the mechanism before claiming the benefit

Consider a hypothetical pipeline that receives dates from an external system. A validation rule checks whether an input has an acceptable form. The application then needs an intentional response to a record that fails the rule.

The feature is the validation. The functional benefit is that an invalid input can be detected at a defined boundary rather than silently accepted. The operational benefit depends on the rest of the design. A rejected record needs to be visible, retrievable and handled without losing information the business needs.

An assertion that validation prevents every crash would skip those dependencies. An assertion that it saves a particular number of engineering hours would require a baseline and measurement. A buyer can still understand its value without either claim: the team has a defined way to identify the invalid record and decide what happens to it.

That explanation also gives an engineer something to build and a customer something to test. A phrase such as "peace of mind" can describe a desired feeling, but it can't decide whether the failure handling is adequate. The functional account provides the basis for that judgment.

The drill should run in the other direction too. A claimed business benefit needs a mechanism that could produce it. If the pitch says the buyer can make a more informed allocation, the scope should identify the information they receive and the decision it supports. A new dashboard with unrelated charts won't satisfy that promise.

Benefits connect function with economic and emotional value

My working notes separate functional, economic and emotional value. These are perspectives on the same proposed change.

The functional question asks what becomes possible or more dependable. The economic question asks how that affects revenue, cost, time or risk. The emotional question asks what difference the customer says that practical improvement would make to their experience.

A sales-follow-up system illustrates the connections. The function might be to assign each enquiry and expose whether follow-up occurred. A possible economic effect is less missed opportunity. The customer's desired experience might be an end to checking every enquiry personally. The last two remain intended benefits until the operation produces evidence for them.

A proposal should show the distinction. A measured result, an estimate, an intended effect and a customer's aspiration can all be useful. They shouldn't appear as interchangeable claims in the same paragraph.

Revenue, time and risk are the dimensions I look for in the economic explanation. Revenue needs to retain its distinction from profit. Time saved by one person may become work for another. Risk reduction needs to specify which failure is less likely or less damaging, and what remains outside the design.

The exercise can reveal that a proposed feature isn't worth building. A capability may sound impressive and have no credible route to a benefit this customer values. That's useful to learn before the feature becomes a delivery commitment.

Keep a working list of supported benefits

I collect the results in what my notes call a benefit bucket. Writers and people preparing proposals can use that shared list. Its purpose is to keep the team from inventing a new claim whenever a page or email needs finishing.

A useful entry contains more than an attractive sentence. It records the current situation, the proposed difference, the feature or work that supports it and any condition the benefit depends on. Where there's evidence, the entry points to it. Where the team still needs to test, it says so.

The list should be broad enough to expose different reasons customers might buy. It should also preserve differences between buyers. A feature that helps a specialist inspect a failure may add confusing detail for a casual user. A benefit that matters to an operator may need a separate explanation for the person approving expenditure.

The language can become more natural as it moves into a message, but the conditions must survive. Turning an entry about reducing one manual task into a claim that the whole team becomes more productive would add a conclusion the evidence never established.

A reliable supplier is one benefit that my notes return to. Buyers need the promised result to arrive under the agreed conditions, and they need a useful response when something goes wrong. The copy can describe how delivery will work. Stage 9 has to demonstrate it.

The next set of questions broadens that benefit list beyond the most obvious functional improvement. It helps identify what the customer means by value before the team assumes every buyer wants the same thing.

Benefit questions reveal different reasons to buy[summarize]

The benefit prompts in my notes are Have, See, Feel, Eat, Do, Know, Meet, Status and Moral Struggle. I use them to ask different questions about a customer's future. They're a way to examine value, not a finding that every person buys for a hidden emotional reason.

A product can be relevant to several of these questions. It can also have nothing useful to say about one of them. Forcing a benefit into every category would produce the kind of copy the exercise is supposed to prevent.

Possession and daily experience answer different questions

Have asks what the customer will possess or have access to. A report, a functioning tool or a completed installation can answer it. The object alone doesn't explain the value, but it gives the benefit a concrete starting point.

See asks what becomes visible in the customer's normal experience. A working report might let an owner see which accounts need attention. A change to a physical product might affect what a customer sees in their home. The question helps separate possession of a deliverable from the experience of using it.

Feel asks about the customer's account of that experience. They might value reduced uncertainty, greater independence or enjoyment of a purchase. I need their language here. Assigning an emotion because it makes a persuasive sentence is different from learning that the buyer values it.

These questions can check one another. If I can describe how a product will supposedly make someone feel but can't identify anything they'll have, see or do differently, I may be relying on an unsupported impression. The functional explanation needs enough substance to carry the emotional claim.

Eat is a deliberately concrete reminder that benefits can involve ordinary consumption and daily routines. It can be directly relevant to food or a kitchen product. It may have no useful application to an infrastructure engagement. I'd leave it empty rather than manufacture an analogy about feeding the business.

Do asks which action or activity becomes possible. A customer can compare records, prepare a meal, share a result or complete a task they previously needed help with. The useful answer names the action and its conditions. Saying that the customer can "do more" postpones the explanation.

Knowledge can mean access, understanding or predictability

Know deserves careful treatment because it can conceal several different benefits. A customer might want access to information. They might already have the information and need help understanding it. They might want a dependable basis for a forecast or enough evidence to choose between alternatives.

Those are different promises. A reporting system can make the current position more visible without making next month's demand predictable. A supplier who describes the two as equivalent has expanded the claim without expanding the evidence.

My notes associate knowledge with clarity, confidence, certainty, predictability and insight. In practice I want to ask which of those the customer means and how much certainty is available. A clearly stated limitation can be more useful than a confident number whose error is unknown.

Meet asks about access to people. A community or programme might help a buyer find peers, collaborators or people with relevant experience. The offer should state what access it provides. Membership alone can't promise that another person will become a useful contact or customer.

That distinction matters in services too. An introduction is something a supplier can arrange with permission. The outcome of the relationship belongs to the people involved. Copy that merges the introduction with a guaranteed commercial result misdescribes what's being sold.

Status can mean keeping a position as well as gaining one

Status asks how the customer wants to be regarded and by whom. A professional might want to be trusted with a larger responsibility. Another might want to keep doing work they value without being pushed into a managerial role. Both can be relevant. Assuming that everyone wants the more impressive title can lead to the wrong offer.

The question can also explain why a technically adequate product is unsuitable. A buyer may need something their own team can understand and defend. If that product makes them permanently dependent on an outsider, the apparent capability gain may come with a loss of control they won't accept.

I wouldn't turn that possibility into a claim about a reader's private insecurity. Ask what responsibility they want to carry, what they want to hand over and which expectations they need to meet. The answers provide a usable account of the future without a consultant diagnosing their identity.

Moral Struggle asks what the buyer believes is the right way to act and what constraints that belief creates. It can involve competing obligations. A business may care about sustainability and also have a responsibility to keep a purchase affordable. The product needs to fit the actual decision, including how the buyer weighs those obligations.

A mismatch here isn't permission to accuse the buyer of hypocrisy. It's a reason to ask more precisely what they can approve and what evidence they require. A seller can share a value with a customer and still offer the wrong way to pursue it.

The categories need to return to the same future

The prompts are useful when they add a distinction that changes the work. A customer buying a reporting system may need a deliverable they can own, information they can inspect, an action they can take and a way to explain the decision to colleagues. Those are connected aspects of one job.

The benefit list should preserve that connection. A collection of impressive claims about status, freedom and certainty can describe a different product from the one in the scope. Each benefit needs to remain attached to the evidence and responsibilities established in the People phase.

Reliable delivery supports all of them. The supplier's promise needs to mean the same thing in the conversation, the written offer and the customer's experience after payment. The message has to explain that value in words the customer understands and would use.

Stage 5 builds the message from the customer's words[summarize]

Messaging connects the benefit to a person who has a reason to care about it. I start with the customer language collected during diagnosis, then use what we learned about the future and the change required to reach it.

The curse of knowledge makes this harder for a supplier than it looks. I know why a technical choice matters. A customer meeting that choice for the first time may only hear an unfamiliar noun. Repeating it in a louder headline doesn't explain the consequence.

My notes use teraflops as an illustration. A technically informed buyer can use a hardware specification to make comparisons. Another buyer needs to understand the experience the hardware can support. Both deserve accurate information, but they need different entry points.

Translate the experience without losing the mechanism

Imagine a seller comparing products in flumpkins, an invented unit. A seller can claim to have more flumpkins than a competitor and still tell the buyer nothing. Producing an explanation of the unit can also miss the question the buyer was trying to answer.

The exercise is to say what changes in use. A technical specification should be available to the person who needs it, while the practical consequence provides a reason to inspect it. The claim about the experience still has to be true. Translating a specification isn't permission to turn it into a capability the product doesn't have.

I use the customer's actual words to choose the entry point. A person who describes an agency failing to respond is raising a different concern from someone asking about targeting options. A message about sophisticated campaign management may leave the first concern untouched.

Borrowed phrasing doesn't mean every raw sentence should appear unchanged in an advertisement. The wording may need context, permission or a clearer reference. What must survive is the concern the customer expressed. Replacing it with the company's preferred category can remove the reason it was useful.

A message can address a concern without inventing agreement

Blair Warren's relational checklist asks the writer to consider suspicions, fears, past failures, dreams and enemies. Those prompts describe things to understand about an audience. They need boundaries when turned into copy.

Confirming a suspicion requires knowing whether it's true. A customer may believe their current tool was designed for a different scale. The response should investigate the limit and explain it. Agreeing because agreement is persuasive would make the writer responsible for a claim they haven't checked.

Quelling a fear requires evidence or a concrete safeguard. A buyer concerned about disrupting an operation may need to see how a test is isolated and what would stop a release. Telling them there's nothing to worry about supplies none of that information.

Understanding a past failure can remove misplaced blame. It can also reveal an action the customer will have to change. The message needs to preserve both possibilities. Reassurance that excuses every decision can conflict with the change commitment the project actually requires.

Believing in a desired future means taking it seriously enough to establish what would make it possible. It doesn't require endorsing an implausible outcome. A clear plan and its limits show more respect for the buyer than a promise the supplier can't support.

Naming an enemy is especially easy to misuse. A real constraint, such as an incompatible data format or an opaque approval process, can give a message specificity. Inventing an adversary or attacking an unnamed industry doesn't establish the product's value. I want the claim to remain useful after the accusation is removed.

The message gives the reader a route to a decision

I use eight questions to connect a sales message to the diagnosis. They help keep the future, diagnosis and next step connected. Their depth and order should fit what the reader already knows, rather than forcing every email to repeat the whole history.

A message can work through these questions:

1. Where does the customer want to be?
2. What's happening now?
3. What consequence follows if the condition continues?
4. What have they already tried, and what did that reveal?
5. What external constraint or mistaken assumption needs explaining?
6. What unresolved belief or concern affects their decision?
7. What method could produce the required change?
8. What concrete step should they take next?

The first three come from the People phase. They shouldn't be invented when the writer reaches a blank headline. If the consequence is unknown, the message should reflect that uncertainty or the diagnosis needs more work.

The middle questions explain why another attempt might differ. They can describe a failed approach without claiming every previous supplier was incompetent. A method can have been reasonable under different constraints. The distinction should come from the evidence, not from a convenient story about why this supplier is superior.

The method then gives the buyer something they can evaluate. It should describe the work from their side. Buyers need to know what information they supply, what decision they make and what result they receive. Internal tool configurations belong where they answer a buyer's question about delivery or reliability.

This distinction between method and internal process is useful in technical services. A demonstration of how the team operates its own software can be accurate and still leave the customer unsure what will happen to their enquiry. Describe the customer action and consequence first, then provide the operational detail needed to substantiate them.

The next step needs to be specific and proportionate to the evidence. A reader who's still comparing approaches may need a diagnostic conversation. A buyer who has agreed scope may need the written terms. Asking both for the same commitment ignores the difference in their position.

The vocabulary has a history and can become stale

Customer language changes as their situation changes. A phrase gathered from an old review can still be useful, but it shouldn't be assumed to represent the current market. A new competitor, platform rule or product change can alter what the same words mean.

The language collection therefore needs a source date and a route for new evidence to update it. A team can keep an effective phrase while continuing to test whether the concern underneath it remains important. Familiar wording alone doesn't establish continued fit.

A complete message also needs an appropriate setting. A sales page can carry a developed argument. An email to a person who already bought needs to acknowledge the existing relationship. A sequence should advance that relationship through relevant information and decisions, rather than sending every reader the same pitch repeatedly.

A sequence should respond to the relationship the buyer has[summarize]

A person who has never engaged with a business needs a different message from a person comparing its offer. An existing customer has another relationship again. Segmentation makes those differences part of the design.

My email work starts by asking what the recipient knows, what they've done and what the next useful action would be. A cold prospect may need education about the problem or evidence that the business understands it. An engaged prospect may need the offer and its terms. A previous buyer may need help using what they bought before another offer makes sense.

The labels cold, warm and past buyer are a starting point. They don't settle what any one person needs. A click can indicate interest in a particular subject without establishing readiness to buy. A purchase can indicate a transaction without establishing satisfaction.

The supplement work began with a relationship problem

I worked with a fitness-supplement business that already sold substantial volume through Amazon. Its direct relationship with buyers was much less developed. The opportunity was to build an owned channel in which the business could answer concerns, explain its product and make a relevant offer.

The historical project used addresses retrieved from Amazon sales data. That describes how that campaign's list was assembled. It isn't a present-day permission model for contacting marketplace buyers. Access to an address and permission to market to its owner need separate treatment. A new engagement needs an appropriate basis for contact and a functioning way for recipients to stop it.

The strategic distinction in the work was between a list of transactions and an audience that had chosen to engage with the business. We treated the initial relationship as something to develop, then used engagement to inform a more direct conversion sequence.

The first phase addressed questions and resistance around supplements. Product efficacy, ingredients and use gave the messages subjects buyers had reasons to care about. Customer reviews and competitor feedback supplied vocabulary and concerns, rather than having the brand announce whatever it wanted to say about itself.

The second phase sent a more conversion-oriented sequence to the engaged segment. The work used benefits, relevant responses to concerns and risk reversal through the offer's actual terms. A guarantee needs to be something the business provides. It can't be added by a copywriter because the email would be more convincing with one.

The useful structure was education and relationship followed by a relevant sales decision.

Direct email revenue and paid performance were different results

The email work generated roughly $50,000 a month in additional direct revenue in the account I described. Engaged visitors also supplied activity the PPC team could use in its targeting and site measurement. My account reports an additional roughly $100,000 a month in paid-ad performance associated with that work.

I wasn't running the PPC campaigns. My responsibility was email and some conversion work on the website, in collaboration with the PPC team. That division matters. The cross-channel result shouldn't be presented as though I personally operated every part of it.

It also isn't an experiment isolating email as the sole cause of the paid result. Audience, site and advertising decisions interacted. The lesson I take from it's to make the cooperation explicit enough that useful engagement can inform the other channel, while keeping the measurement and responsibility for each result distinct.

A direct email sale, a later sale after several contacts and an improvement reported in paid performance aren't automatically separate incremental purchases. Measurement needs to explain which event is being counted and how attribution treats overlapping contact. Adding every channel's reported revenue can overstate the business result.

I want hard commercial and behavioural measures alongside engagement. Opens and clicks can help identify what to investigate, but the questions continue through purchases, add-to-cart behaviour, checkout starts, average order value and repeat orders. A sequence can attract attention without producing a viable customer relationship.

Each message needs an action the recipient can understand

A sequence should have a reason for its progression. Education can answer a concern. Evidence can show how the product addresses it. An offer can state what the buyer gets, what it costs and what happens if it doesn't meet the agreed conditions. The order should fit the actual relationship.

One useful action per message gives the writer a decision about what belongs. A request to read an explanation has a different job from a request to purchase. Asking for a reply can be useful where that reply changes the recommendation. An action added simply to improve a click metric may make the sequence less relevant.

The automation needs to respect what happens next. A customer who buys shouldn't continue receiving a sequence written for somebody who hasn't. A person who asks for help needs a route to that help. A person who opts out needs the contact to stop. Those transitions are part of the message's credibility.

Testing should retain the question the message was intended to answer. A higher open rate might suggest that a subject line gained attention. It doesn't establish that the content made the offer clearer or that the business made more profit. The next decision depends on the measure appropriate to the job.

The same applies to the less visible parts of the sequence. A reply address, landing page and checkout promise need to agree with the email. An attractive message leading to a contradictory offer creates a delivery problem before anyone pays.

The supplement work was useful because the message treated concerns as material for a conversion system and connected that work with the people responsible for the site and ads. Its value came from the relationship among those decisions. The written offer has to preserve that relationship when it states what the buyer can hold the business accountable for.

Stage 6 puts the promise and its limits in writing[summarize]

An offer is an agreement about the change the customer is buying. Price is part of it. So are scope, deliverables, responsibilities, timing, evidence and the response when delivery doesn't meet the agreement.

A service label leaves most of those questions open. Advertising management can mean maintaining existing campaigns, researching a new audience, rebuilding measurement or taking responsibility for a defined testing programme. A buyer comparing the labels can't tell which of those jobs a quotation includes.

The offer should make the comparison possible. A distinctive method can explain why the approach suits the problem, but a proprietary name doesn't remove the need to describe the work. The buyer still needs to understand what will happen and what they can expect to receive.

The offer connects the outcome with accountable work

I want the intended outcome stated in the customer's terms, followed by the work that could support it. The distinction between intended result and committed output must survive into the agreement.

A testing project might aim to find a viable acquisition approach. Its committed outputs could include the agreed experiments, the campaign records, an analysis of the observations and a recommendation based on them. A finding that the tested approach is unsuitable can fulfil that research contract, provided the work and its limits were described accurately.

A technical project can have a more direct functional acceptance condition. A named operator provides a real input, performs a specified task and can inspect the resulting state. The agreement should also describe relevant failure handling. A demonstration with invented data doesn't establish that the client's actual job works.

Scope then says what's included and excluded. Customer responsibilities identify access, decisions and information the provider can't supply alone. Timing needs to reflect dependencies rather than an unqualified promise that begins before those inputs exist. The commercial terms should say how a change to scope is agreed.

Risk reversal belongs inside that structure. A remedy can require the supplier to correct work that fails the acceptance condition or make a specified payment milestone conditional on delivery. The remedy needs clear conditions and an obligation the supplier can responsibly accept.

The offer explains the method, price and delivery risk

My notes borrow offer-construction ideas from Alex Hormozi's Grand Slam Offer approach. The useful levers are the mechanism, the price comparison, risk reversal and additions that answer a particular objection. They need to describe a real agreement rather than decorate a quotation.

The mechanism explains how the work will produce the proposed change. A name can make it easier to discuss a recurring method. It can't make interchangeable work incomparable by declaration.

The price comparison can show what the current problem costs or what another approach would require. That comparison needs a defensible basis. Revenue at risk isn't automatically a recoverable saving, and a customer's aspiration isn't a forecast. A buyer should be able to distinguish the known cost from the estimated opportunity.

Risk reversal answers what the supplier will do if it fails a controllable commitment. It shouldn't quietly convert a method into a revenue guarantee. My own position on campaign results is that I can guarantee my process and output, not that every product will earn a particular return.

Additional materials can make the agreement easier to use. Documentation, templates or access to a real support arrangement can answer a delivery concern. A pile of unrelated bonuses makes the scope harder to evaluate. If a proposed addition is necessary to achieve the promised result, it belongs in the core delivery rather than being presented as optional generosity.

The coaching launch combined learning with implementation

The Facebook ads coaching engagement joined work that buyers often had to purchase separately. The offer included a way to learn the advertising system and practical help with the buyer's accounts. That combination mattered to people who needed both capability and assistance applying it.

I helped put the programme and funnel together, wrote sales material, took the sales calls and served as head coach in the community. It was a team effort. I wasn't the person solely responsible for creating the whole programme.

The sales included coaching packages and more expensive agency implementation work. In my account, coaching was roughly $3,000 to $6,000 and the agency services were roughly $10,000 to $20,000. Treating those as one uniform coaching price would misdescribe what the buyers purchased.

I personally closed about $199,500 in the first 30 days. I still remember being annoyed that it wasn't $200,000. The useful part of that number for another supplier is the relationship between the offer and delivery: I was involved in both the selling and the work that followed, so the promises couldn't be treated as somebody else's problem after the call.

The result doesn't establish a universal close rate for hybrid offers. It also doesn't mean that increasing a price automatically creates demand or status. The package addressed a specific audience with a particular need for learning and implementation. Another audience may need a different agreement.

The written version should expose an incomplete offer

Before presenting the offer, I want answers to five questions. They connect the intended outcome, evidence and commitment in a way a buyer can inspect.

1. What result is the customer seeking, and what exactly are we agreeing to deliver?
2. What evidence supports the approach and its claimed capability?
3. What acceptance condition and remedy hold the supplier accountable?
4. What makes the buyer and supplier suitable for this agreement?
5. What comparison explains the price without inventing a return?

The answers can reveal a problem upstream. An outcome nobody can describe sends the work back to the future stage. A benefit without evidence needs investigation. A scope that depends on unavailable customer information needs a different agreement or a decision to stop.

A technical offer particularly benefits from that discipline. A phrase such as "build an AI agent" leaves the job, the operator, the inputs and the proof unspecified. A bounded functional agreement can name those things without promising that the system solves every related problem.

The buyer should also be able to identify the supplier's limits. A test budget, an access dependency or an unsupported use case may change whether the engagement is worthwhile. Hiding those conditions until after payment creates precisely the mismatch qualification is meant to catch.

The offer is ready for a decision when the parties understand the same obligations. It still needs a buyer who can use, fund and participate in the work, and a supplier who can fulfil it under those conditions.

Stage 7 checks fit in both directions[summarize]

Qualification asks whether the agreement can produce useful value for this buyer under the conditions that actually exist. It also lets the buyer decide whether this supplier is suitable. Both decisions need evidence.

My qualification pitch starts with a business owner who has looked at advertising performance and wondered whether a better result is possible. That identifies a problem I can investigate. Saying that every business owner is my customer wouldn't tell either party much about fit.

The decision also has to account for delivery capacity. A customer can be able to pay and still need something I can't responsibly provide. A supplier can be technically capable and still be the wrong choice for the customer's particular job.

Fit includes the cost of acting on the advice

I distinguish the fee from the resources needed to use the work. A strategy that requires testing, implementation or ongoing maintenance can be unaffordable even when the buyer can pay the initial invoice. Qualification needs to surface the whole commitment.

I check budget, authority, need, timeline and engagement before deciding whether the work fits.

Budget asks what the business can allocate to the agreement and its dependencies. Authority asks who can approve it and who else needs to be involved. Need asks whether the problem fits the proposed work. Timeline asks when the work becomes useful and what other events constrain it. Engagement asks whether the parties can provide the participation the delivery requires.

Those answers can change over a conversation. A person without signing authority may still be the internal champion who understands the job best. The useful response is to identify the approval process, not dismiss the person for having a manager.

Responsiveness needs context as well. A delayed reply is information about the interaction. It doesn't establish a person's character or predict every part of delivery. A project requiring frequent decisions needs an agreed way to obtain them. If the buyer can't support that arrangement, the process may need to change.

The buyer is doing their own qualification. They may need evidence that the supplier understands their market, can communicate with their team and will leave them able to operate the result. A provider should make those questions answerable through relevant work, a clear method and explicit responsibilities.

An application changes the conversation before it changes the calendar

The long-form application in my agency work asked prospects to provide information before booking. My PPP notes describe a question about profit the prospect wanted to add over the next 90 days. The bands were under $10,000, $10,000 to $50,000 and above $50,000; the lowest band was excluded from the calendar. That was a screening rule in a particular approach, not a measurement that ambition equals available cash.

A good screen needs a reason tied to the offer. A prospect can name an ambitious profit target and have no implementation budget. Another may have a modest target and be an excellent fit for a smaller service. The answers should support a decision the business can explain, and ambiguous answers need a route for clarification.

The lead-generation account also involved more than a form change. Audience testing, creative variation and offer positioning contributed. We used video engagement campaigns to build an audience before asking for a higher-commitment conversion, then refined the form to help qualify the people coming through.

In that account, I described lead costs starting around $200, reaching a profitable point around $50 and later observations around $10, $12 and $18 while maintaining quality. That's a sequence of figures from a particular recollection. It shouldn't be compressed into a single universal before-and-after for every agency campaign.

The shorter case summary describes moving qualified leads from roughly $50 to under $10. Those figures use a qualification definition. A comparison is only useful if the team knows what was counted at each point. Cost per form submission, qualified lead, appointment and sale are different measures.

The form affected which action the system could use as a signal. Completing a more demanding application can provide different information from clicking an advertisement. Whether that leads to better business depends on what the form asks, which event the campaigns use and what sales later reports. The campaign's optimisation event needs to represent the action the business wants to encourage.

A gate needs a useful outcome for the person it excludes

A qualification decision should have a stated reason. The business might lack capacity, the scope might require unavailable access or the economics might not support the work. A courteous decline can explain the relevant boundary without treating the person as a waste of time.

The same applies to people exploring options. They may need information rather than a proposal. A resource that helps them understand the problem can be appropriate. Sending them through a sales process they aren't ready to use imposes work on both parties.

The seller also needs to check whether the gate is doing what was intended. A fall in raw lead volume can accompany better-fit conversations, or it can mean suitable people abandoned an unnecessarily difficult form. The number alone doesn't distinguish the two. Look at the people excluded, the information lost and the outcomes after the gate.

Qualification should therefore be revisable. A bad engagement can reveal a missing criterion, but it can also reveal a delivery defect the supplier needs to own. Adding a rule that excludes every customer affected by a provider's failure would protect the wrong thing.

This method suits work in which diagnosis, participation and evidence can change the scope. A buyer who needs a fixed, already-defined purchase may reasonably choose a simpler transaction. A buyer who wants a supplier to guarantee market demand is asking for a promise I don't offer.

The next conversation is often about budget. It should establish what's known, what's undecided and whether there's a responsible way to investigate further before either party commits to the larger engagement.

Budget and discovery establish what can be responsibly offered[summarize]

The budget question belongs before a supplier invests substantial effort in an agreement the buyer can't fund. Ask what budget has been allocated, then give the person room to answer.

The silence matters because adding an explanation immediately after the question can turn it into a different question. I want to hear what's available and what has already been decided. I don't need to guess a person's finances from their reaction to an awkward conversation.

An answer can reveal several different situations. The buyer may have an allocation but need to confirm approval. Buyers may know what they can spend but prefer not to disclose it yet. They may need help scoping the work before establishing a budget. They may have no realistic way to fund the proposed engagement.

Each situation calls for a different next step. Treating all of them as a lack of trust or ambition would conceal the distinction qualification needs to make.

Ask what the budget has to cover

A meaningful budget answer needs a currency, an amount or range, and a scope. It may cover the supplier's work, advertising expenditure, internal staff or some combination. A fee that fits the number can still leave the project unfunded if the buyer expected every dependent cost to be included.

The supplier can explain a relevant price range or a minimum engagement where those are real terms. That lets the buyer decide whether further discussion is useful without having to reveal every financial detail. A quotation still needs enough information to state what that price buys.

A discussion of value can help define the investment, but arithmetic has to retain its meaning. Expected revenue is different from profit. A possible saving is different from cash available to fund the work. A revenue target divided by a fee isn't a return the supplier has established.

I also want to distinguish a testing allocation from money the business needs for essential obligations. A customer staking everything on an uncertain campaign may need a different recommendation from one who can fund a defined experiment. Qualification should make that risk visible, even when accepting the fee would be easier.

A smaller budget can justify a smaller useful job. It doesn't justify promising the same result while quietly removing necessary work. The question is whether the narrowed scope can still serve a coherent decision or outcome.

Paid discovery must produce something worth keeping

A deep investigation can be a separate engagement. It should have its own scope, price, required inputs and usable output. A buyer should understand what they keep even if they choose another supplier for implementation.

That output might be a written diagnosis, an options analysis or an implementation brief. The nature of the problem decides which is useful. An extended sales call presented as a paid diagnostic would leave the customer paying to hear a proposal rather than receiving work they can use.

Any arrangement to credit the discovery fee against later work needs to be agreed explicitly. It isn't an automatic property of paid discovery, and the copy shouldn't offer it on the supplier's behalf unless it's part of the real terms.

The investigation can also change the recommendation. A paid diagnostic that can only conclude "buy the larger package" hasn't left much room for the evidence. A valid finding may be to retain the current system, solve a prerequisite or decline the proposed investment.

The promise is the quality and usefulness of the investigation. It needs appropriate access to records and people, and it needs to preserve uncertainty where the evidence can't settle the cause. A longer report isn't a substitute for that distinction.

Go wide before choosing what to investigate deeply

Discovery can start by collecting goals. Ask what the customer wants to achieve and what else matters, then ask which goal should take priority. Explore why that one matters before assuming its wording already describes the whole need.

Run a similar exploration on problems. A customer may initially describe several frustrating tasks. Asking which produces the most consequential difficulty can reveal a constraint the initial service request didn't name.

The purpose of the wider list is to avoid committing to the first plausible answer. The deeper questions then establish relationships among the priority, its consequence and the required work. The customer should be able to correct the interpretation as it develops.

The conversation can produce language for the later message, but permission still matters. An explanation of a private operating problem doesn't become a public testimonial. The written diagnosis can preserve what's needed for the engagement without unnecessarily exposing the people involved.

The findings should return to the problem statement and future description. If discovery changes either, the offer needs to change with it. Leaving the original promise untouched while the team works on a new diagnosis creates incompatible agreements within one project.

Automate a decision the business can explain

A form and workflow can handle parts of qualification. They can gather answers, apply agreed criteria and route an enquiry to booking, clarification or a courteous decline. They shouldn't convert a missing answer into a confident interpretation.

The automated route needs an owner. Someone has to maintain the criteria, review ambiguous cases and check whether the information reaching sales is the information the prospect supplied. A scoring rule that nobody can explain becomes difficult to challenge when it excludes a suitable buyer.

The manual process should first establish what the decisions mean. Automation can then repeat the parts that are genuinely repeatable. If a team can't say why one enquiry should proceed and another shouldn't, a more elaborate workflow will preserve that uncertainty in code.

Discovery and qualification have now supplied a possible agreement, a view of fit and any remaining questions. The sales path can use that information to give the person a decision they can make, with the relevant evidence and next action available at the same point.

Stage 8 gives each buying step a clear job[summarize]

The sales process includes everything between first encountering the business and receiving the value that makes someone willing to recommend it. My shorthand is stranger to superfan. A call is one possible part of that process. A product page, application or first-use workflow can do much of the same work in a different setting.

The stages before this point should have established the customer, the relevant future, the change required and the agreement on offer. Sales now needs a path that lets a person evaluate those things and decide what to do.

A useful path makes each step's job clear. The first contact establishes relevance. A landing page provides context. An application or cart records a possible commitment. A diagnostic conversation or trial helps evaluate fit. A proposal or checkout states the terms of the exchange.

The steps don't all have to be separate pages or events. A simple purchase can combine several. A complex service can need more information and more participants. The design should follow the actual decision rather than imitate another business's funnel.

A page can carry a conversation the buyer needs

I think of a landing page as a presentation arranged vertically. People can inspect its shape, return to a heading, examine a claim and decide whether to continue. The writer needs to serve those different reading behaviours without assuming every visitor reads the whole argument in order.

The opening should make the offer intelligible. The body should explain the relevant benefit, provide evidence and address questions that affect the decision. The action area should state what happens when the person proceeds.

Small statements near that action can carry substantial obligations. Shipping conditions, cancellation rights and a refund policy need to be real. A reassuring phrase copied from another store can accidentally create a promise this business can't fulfil.

The kitchen-gadget campaign is one of my early examples of testing the whole page rather than arguing over its appearance. I studied e-commerce conversion work and built three substantially different landing pages for an avocado slicer. The pages used different styles and presentations, and we allocated budget to test them.

The page I thought was ugliest performed best. The account generated roughly $600,000 in sales in under 60 days from that campaign. It was a favourable environment for testing, with budget and an offer that could find buyers. I wouldn't turn it into a claim that ugly design always sells better.

The more useful conclusion is that my aesthetic judgment didn't settle the commercial question. The pages needed to be tested as propositions in the actual buying path. The record doesn't isolate a particular headline, colour or checkout phrase as the cause of the result.

A demonstration should answer a stated problem

A technical demo can become a tour of everything the supplier built. That gives the presenter plenty to explain and may leave the buyer's question unanswered.

The approach in my notes is to connect a demonstrated capability with a problem the prospect has actually described. Ask whether seeing that job performed would help their decision. Then show the job, including the input and the result, rather than treating every setting as equally important.

A buyer assessing reconciliation work needs to see what's reconciled and what happens to a mismatch. A successful animation of the interface isn't equivalent to a successful reconciliation. The demonstration needs a truthful relationship with the work being sold.

A trial has the same responsibility. The first-use experience should guide the user to something useful and make limitations visible. An empty account may need setup assistance. A sample can explain how the product works if it's clearly labelled and kept separate from the customer's real results.

Enterprise sales adds another participant problem. The person using the tool may need to explain it to the person approving expenditure, or to people responsible for risk and operations. The supplier should help those people evaluate the same agreement rather than leaving the initial contact to reconstruct it from a demo.

The build-versus-buy question then becomes an allocation decision. An internal team may be capable of building the tool. The comparison needs to include ongoing maintenance, support and the other work that team would defer. It also needs to include the costs and constraints of buying. A generic claim that building always wastes engineering time wouldn't help the buyer make that comparison.

Measure transitions before choosing what to change

The sales path should provide enough information to locate a problem. A final revenue total doesn't show which part of the path needs investigation.

The familiar measures differ by business, but each needs a defined population and event.

A rate needs both its numerator and denominator. A close rate among attended qualified calls means something different from sales divided by every enquiry. A conversion improvement after a qualification change may partly reflect a different group reaching the call.

The period and source also matter. A campaign with a long buying cycle can have spend recorded now and sales recorded later. Comparing unmatched periods can make an improvement or failure appear where the measurement simply hasn't caught up.

These symptoms can point back to earlier stages. A declining close rate is a reason to inspect qualification and the offer. A falling show rate invites questions about expectations and follow-up. A poor trial-to-paid rate can point to onboarding or a mismatch between the promise and the product.

Those are routes for investigation. They aren't diagnoses from a dashboard. The close rate could also change because of price, season, sales capacity or a measurement problem. Check what the number actually records before deciding which stage failed.

The path has done its job when the person has relevant evidence, understands the terms and can take a clear next step. The remaining work in the sales conversation is to ask for that decision without filling every pause with another pitch.

A close asks for a decision and leaves room for a response[summarize]

A close states the next action that would make the agreement real. It can be a signature, a payment or another explicitly agreed commitment. The action should follow from the conversation the parties have already had.

The distinction between selling and closing is useful here. Selling establishes relevance, explains the work and supplies evidence. Closing makes the decision available. A seller can keep explaining after the buyer has enough information, leaving the practical question of how to proceed unanswered.

The approach in my notes is listen, agree, close. Listen to the concern, identify what's true or reasonable in it, then establish whether the next step still makes sense. The agreement part needs to be genuine. Repeating a line of agreement while ignoring the concern wouldn't serve the buyer or the eventual delivery.

An objection can reveal missing information

A request for a decision can expose a concern that remained invisible during the presentation. The person may need approval, may not understand a term or may doubt that the work addresses their situation. That information is useful even when it means the sale shouldn't proceed.

An objection can also be a refusal. The fact that someone raises a concern doesn't establish that they secretly want to buy. The supplier needs to hear the person's response, including a decision to stop.

The next action depends on what was missing. A question about implementation might need a technical explanation. A question about responsibility might need a change to the written scope. A lack of approval authority might require another participant. Repeating the benefit story doesn't resolve those problems.

The same applies when the buyer asks a narrow question after a long presentation. Answer it at the level it was asked. A request about the payment schedule doesn't automatically call for another account of why the product is valuable. The seller's uncertainty about the decision shouldn't become extra work for the buyer.

A second request for a decision can be appropriate after the issue has been addressed. It should refer to the revised or clarified agreement. The point is to give the person a choice they can make, not to keep changing the wording until they give a response the seller wants.

A price concern needs its own diagnosis

A price complaint can raise a different question from doubt about the product. That distinction is useful when it prevents the seller from treating every mention of money as a request for another pitch. It shouldn't become a rule that money can never be a genuine barrier.

A buyer can believe the work is worthwhile and still be unable to afford it. They can have the money and prefer another use for it. They can also be comparing a different scope and need help understanding the difference. Those possibilities require different responses.

A supplier can acknowledge that a price is substantial and ask which aspect of the agreement needs reconsidering. A scope change may reduce the price while preserving a smaller useful job. It should also remove the corresponding promise. The provider can't remove necessary delivery work and leave the same outcome in the pitch.

An unsupported discount has its own risk. It can leave the customer unsure what the original price meant or leave the supplier without the resources required for delivery. An explained change in scope, responsibility or commercial terms gives both parties something concrete to evaluate.

The comparison with inaction needs care as well. The known cost of a problem can be relevant. A prediction of what the buyer might earn is uncertain. That uncertainty doesn't disappear because the seller uses the prediction to make the fee look small.

Readiness still requires the buyer's consent

The assume-the-sale posture in my notes is a way to participate in a conversation without treating every question as rejection. I can discuss how an engagement would work, explain what starts after agreement and be clear about the action available.

The posture doesn't supply consent. A person agreeing that a problem exists hasn't necessarily approved the proposed solution. A person asking about a service hasn't agreed to buy it. The written terms and the actual decision still matter.

Before asking for commitment, check the conditions that would make the agreement responsible. The relevant decision-maker or approval path should be known. The need and any real consequence should be understood. The offer should state the work, the commercial terms and each party's responsibilities. The buyer should have a route to resolve doubts about the approach and the provider.

A constraint on timing can be part of the real situation. It shouldn't be invented to force the decision. A genuine capacity limit or necessary dependency can be stated plainly. A fabricated scarcity claim would make the message contradict the trust required for delivery.

Silence after asking gives the person room to consider. It also gives them room to identify a concern in their own words. Filling that space with several new questions can make it harder to learn which issue actually matters.

The next step should preserve the agreement

A useful next step states what the person is deciding and what will follow. The buyer should be able to find the same scope and terms in the document they receive. A changed verbal promise needs to be reflected in the written version before work starts.

That's particularly important when the conversation produces a smaller engagement, a separate discovery phase or a new dependency. A seller can reach an apparent agreement while the delivery team still holds the original scope. The handoff needs to preserve the scope and decision that accompanied the payment.

The supplier should also leave a truthful non-sale state. A person can decline, postpone, choose a different approach or need information that isn't yet available. Recording the reason accurately is more useful than marking every unresolved conversation as an objection to overcome.

The close succeeds when both parties knowingly make the same agreement. The next obligation is then concrete: deliver what was promised and make the result usable to the customer who bought it.

Stage 9 delivers the value that was promised[summarize]

The sale creates an obligation to deliver. The customer still needs to receive the useful change described by the offer, understand how to use it and know what to do when something fails.

I include fulfilment in People Product Process because a persuasive message can make a delivery mismatch more expensive. A campaign that attracts more buyers can expose a capacity limit. A convincing software demo can create expectations the handover never meets. Those are reasons to connect the promise with the operation before selling more of it.

The customer's original problem remains the reference. A completed task list is useful evidence of work, but it doesn't by itself establish that the customer can do the job the work was supposed to support.

Onboarding should show what's happening and what comes next

My notes emphasise the period immediately after purchase. The buyer needs a clear account of the next step, what information or participation is required and how they can see progress. That should reflect actual work rather than manufacture a reassuring appearance.

A service customer can receive an agreed plan and the first concrete output when it's ready. A software user can be guided through a useful task. An e-commerce buyer can receive accurate order, delivery and support information. The appropriate evidence differs, but the communication needs to agree with the real state of the work.

A small output helps when it proves something relevant to the larger job. A trivial demonstration can mislead if the supplier presents it as evidence that the difficult integration is complete. The onboarding needs to distinguish what now works from what's still being built.

Physical fulfilment also needs to preserve the benefit. A personalised gift has to arrive in a condition suitable for giving. Packaging, order accuracy and delivery information are part of that experience. That requirement follows from the gift-giving promise.

The same reasoning applies to a dashboard. A buyer expecting to use it for decisions needs trustworthy data, appropriate access and definitions they understand. Installing a visually finished interface while leaving those questions unresolved doesn't finish the promised job.

Capacity has to survive beyond individual effort

I learned about capacity painfully in my own metal shop. I tried to run the manufacturing business and the agency at the same time, took on too much and damaged both. I should have concentrated on what was working instead of treating the ability to bring in demand as evidence that I could operate everything behind it.

Demand and capacity are separate problems. More successful marketing can expose production, staffing or decision bottlenecks. A team meeting current demand through extraordinary personal effort needs to understand what happens when demand grows or the person is unavailable.

The response can be unglamorous: map the order-to-delivery work, identify who owns each transition, make priorities visible and give the team a way to raise exceptions. The design should describe what happens to an order that can't follow the normal route.

This is also the test for a successful handover. Can someone other than the original builder operate the work under the agreed conditions? If the process depends on that builder interpreting every exception, the dependency needs to be acknowledged rather than hidden behind a completed-project status.

Reliability work supports delivery without abolishing failure

In Python systems, my practice has included explicit data models, validation, property-based testing and structured observability. Those choices help define inputs, explore unusual cases and make failures inspectable. Their role in a particular project should follow the actual risks and acceptance requirements.

They don't make every system incapable of failure. A validation rule can be wrong, a test can omit an important behaviour and a log can fail to preserve what an operator needs. The delivery needs to demonstrate the named job and expose the failure conditions relevant to it.

The operator also needs a recovery path. A rejected record shouldn't silently disappear. A task waiting for an unavailable integration should remain visibly waiting. A person responsible for support should be able to distinguish an incomplete job from a completed one.

A system that gives the right answer once under the builder's supervision may still be unsuitable for ordinary use. The useful evidence includes the real input, the result, the limits and the ability to reopen the resulting state. That gives the customer something more substantial than the provider's claim that it worked.

An empty state needs a truthful route to first use

An account with no data can make a product difficult to understand. My notes recommend starter material and guidance so the first useful action is available. The guidance should reduce the setup problem without pretending that setup has already happened.

Templates can show the shape of the work. A working example can let a user inspect behaviour. Sample data can explain a visualisation if it's clearly identified, separated from real records and never presented as the customer's performance.

A sample leaves the production connection unproved when that connection is part of the purchase. The handover needs to state which input the demonstration used and what the customer must still provide. That prevents an attractive first screen from concealing an unfinished delivery.

Usage-based help can also be useful. A person who started setup and stopped may need an explanation of that step. Any follow-up should be appropriate to the relationship and the permissions involved. An automated message shouldn't claim someone has a problem the system hasn't established.

Documentation belongs alongside the working product. The customer needs the prerequisites, the normal procedure, the expected result and the response to a failure. A video can demonstrate the sequence; copyable instructions can make it repeatable. Both need to match what actually exists.

The documentation also needs to identify what the customer can safely change and what requires support. A handover that leaves those boundaries implicit makes the customer dependent on guessing. Delivery is more complete when the person can use the result, inspect its state and seek the right help without reconstructing the builder's intentions.

Reporting makes delivered value inspectable[summarize]

A customer should be able to see what the supplier did and what happened as a result. That becomes especially important when the work runs without much visible activity. Quiet operation can be valuable, but the value needs evidence other than the absence of a complaint.

The reporting should connect to the original agreement. A list of tasks shows activity. A result compared with the agreed condition shows whether the work served its purpose. A recommendation explains what the evidence supports doing next.

My notes use the sequence What, So What, Now What. I find it useful because it separates the event, its interpretation and the decision. Combining those into a single optimistic paragraph makes it harder for a customer to challenge any one of them.

A report should show where interpretation begins

What records the work or observed result. It needs the relevant period, units and source. A campaign report can state spend and recorded enquiries. A software report can state which workflow completed, what input it used and which cases remain unresolved.

So What explains the consequence and the limit of the observation. A lower cost per lead can mean an acquisition improvement, but it doesn't establish profit without the cost, suitability and sales outcome of those leads. A completed workflow can prove a functional condition without proving that every user has adopted it.

Now What states the next decision and who owns it. That could be continuing the approach, changing one part, investigating a contradiction or stopping. The proposed action should follow from the observation rather than appear because a report needs to sound decisive.

For an illustrative report, suppose a team observes more completed applications but fewer attended calls. The event belongs in What. The possibility that the application changed expectations belongs in So What, alongside other plausible causes. A check of the relevant follow-up and booking records belongs in Now What. There's no measured result in this illustration, and the diagnosis remains open.

That separation gives the customer a way to disagree productively. They can challenge the source, the interpretation or the action without having to reject the entire report. It also makes clear which new evidence would change the recommendation.

A dashboard needs definitions and freshness

A shared dashboard can make the work available without requiring a customer to request a report. The access is useful only if the information can be interpreted. The display should identify what the figures count and how current the underlying data is.

An unavailable account shouldn't quietly look like an account with no spend. An incomplete period shouldn't look equivalent to a completed one. A qualification definition shouldn't change while the report continues presenting the same label as though the population were unchanged.

The solar-portfolio work depended on comparing accounts and generating tasks from observed conditions. Those decisions require consistent meaning across the accounts being compared. An attractive aggregate can conceal a difference in definition that makes the comparison unusable.

A customer should also be able to trace a consequential total to its source. That doesn't require every screen to expose every technical detail. It requires an accessible route from the conclusion to the record supporting it, including the limitations that affect the decision.

Transparency can't resolve every concern in a relationship. A customer may be unhappy because the work is late, the result is unsuitable or the agreement was wrong. More reporting helps only when it makes the actual issue visible and supports a response to it.

A review should revisit the agreement as well as the results

A periodic business review can collect what was delivered, what changed and what should happen next. My notes describe using that review to make the value of ongoing work visible. It should also create room to ask whether the next period's work is still justified.

The report can distinguish outcomes already observed from benefits still expected. It can identify a commitment that was missed, the agreed remedy and the evidence needed to close the gap. A supplier who only reports the favourable measures leaves the buyer unable to assess the whole engagement.

The review should also preserve customer contributions. A result may depend on implementation by their team, an offer change or work by another specialist. The supplier's report shouldn't absorb that contribution simply because the supplier prepares the document.

Referrals can follow good delivery, but a referral is another person's choice. A successful engagement doesn't entitle the provider to an introduction or a testimonial. The credible request is grounded in an actual result the customer is comfortable discussing, with permission about how it will be used.

The same standard applies to the next sale. Evidence from completed work can support another recommendation. It doesn't guarantee the next project or justify assuming the customer wants a larger relationship. The next agreement needs its own problem, future and scope.

Reporting therefore completes part of fulfilment and supplies material for renewed diagnosis. A changed customer situation, new constraint or unexpected result should be able to reopen the decision. The framework needs a way to incorporate that evidence after the initial project ends.

Recalibration follows evidence that has changed[summarize]

The initial diagnosis describes a situation at a point in time. A business can change its audience, pricing, product, staff or delivery capacity while continuing to use the same message and qualification rules. A framework that never revisits those inputs can become a detailed explanation of a situation that no longer exists.

Recalibration starts by asking what changed. Identifying that change may justify a small adjustment or a deeper investigation. It doesn't automatically require rebuilding the whole system.

The previous outputs make that work easier to inspect. Compare the current customer language with the recorded concerns. Compare the desired future with what customers now ask for. Compare the offer's dependencies with what delivery actually requires. The differences give the review a subject beyond a general request to improve performance.

Give each review a question

A starting schedule can stagger the work: customer-language and benefit work quarterly, future and offer reviews twice a year, change commitments at renewal, sales-path measures monthly and delivery conditions continuously. Treat that as a starting schedule to adapt, not a measured rule that makes every business improve.

The schedule can be made useful by naming what each review should decide.

A review triggered by an incident can be more important than one triggered by a date. A new platform restriction, repeated delivery failure or change in economics can invalidate an assumption before its scheduled review arrives. The affected commitment should be reconsidered when the evidence changes.

A scheduled review can also conclude that no change is justified. Editing a message merely because the team is tired of reading it doesn't establish that customers need a different explanation. The decision should identify which observation supports retaining or changing the work.

Locate the constraint before moving resources

Look for the constraint that limits what the next improvement can achieve. More traffic may have little value while a team can't respond to qualified enquiries. Better follow-up may have little value for an offer that the audience doesn't need.

A metric can suggest where to investigate, but several conditions may be involved. A change in audience can affect application and close rates at once. A capacity shortage can affect both delivery and referral. The team needs to explain those relationships before assuming one step is the sole constraint.

The review should first check the measurement. Did the event definition change? Are the same populations and periods being compared? Is a missing input appearing as a bad result? A team can spend a great deal of effort correcting a commercial problem that's actually a reporting discrepancy.

Then choose a bounded change with a stated expectation. Preserve the earlier condition and the evidence for the new decision. If the result differs from the expectation, the team can examine the hypothesis instead of reconstructing what everyone thought they had agreed.

The constraint can move after an improvement. A successful campaign can reveal a delivery problem that wasn't visible at lower demand. That doesn't mean the campaign failed. It means the next allocation needs to reflect a different condition.

Failure should update the method without inventing certainty

An unsuccessful engagement deserves the same source discipline as a successful one. What happened, what did the team do, which conditions changed and what remains unexplained? A convenient story about a difficult customer can conceal a missed supplier obligation.

A qualification rule may need revision after a bad fit. The offer may also have been unclear, the promised benefit unsupported or the delivery inadequate. Review those possibilities before designing a screen to keep similar buyers away.

The same care applies to customer beliefs. A person failing to adopt a workflow may have rejected a required change, or the workflow may be unsuitable for their actual work. Calling it resistance before checking the design would repeat the inventory-shaped diagnosis Stage 1 was meant to challenge.

Recalibration preserves the sequence by keeping its inputs open to correction. The purpose is a better decision about the current situation. Sometimes that decision is to make a change within the framework. Sometimes it's to use a narrower tool or stop investing in an approach the evidence doesn't support.

The next action depends on what the diagnosis supports[summarize]

A framework can be applied to the wrong problem. People Product Process helps organise a diagnosis and carry a promise through delivery. It doesn't make a full diagnostic engagement the right purchase in every situation.

A business with a validated offer and a working buying path may need access to more suitable buyers. The next task could be a channel or distribution test. Rebuilding every part of the offer before examining reach would add work without addressing the current question.

A business with poor unit economics needs a different kind of attention. Improving conversion can still leave every sale unprofitable. Price, cost, service design and repeat purchase can affect those economics, so an offer review may be relevant. Persuasive copy alone can't be assumed to repair them.

The wrong-layer errors remain useful warnings. Blaming a person for an impossible workflow can make a replacement inherit the same failure. Building a new feature for an audience nobody has investigated can produce a well-made product nobody needs. Cleaning up a CRM can leave an unsuitable offer unchanged.

Each stage leaves an output somebody can challenge

The framework becomes more useful when its stages produce inspectable work. That doesn't mean every engagement needs nine substantial documents. Several outputs can live together in a short brief, provided the evidence, decisions and unresolved points remain clear.

The output list gives you a way to locate a missing input without repeating the whole diagnostic conversation.

A complete output can include uncertainty. A problem statement that identifies an unresolved cause is more useful than a statement that conceals the guess. A qualification result can be waiting for approval. A delivery record can show a failure and a remedy still in progress.

Those distinctions keep the method connected to the work. A row marked complete because a document exists can hide the same failure as a dashboard that substitutes a sample for missing data.

Run the first pass against an actual decision

Choose a product, service or engagement whose next action is genuinely open. The question might be whether to revise a message, fund a test, rebuild a buying step or accept a customer. A closed decision presented as research will encourage the team to collect only supporting evidence.

Start with what's already known. Gather the relevant customer accounts and business records, keeping exact language separate from interpretation. Record which buyers and situations those sources represent. The aim is to understand the decision, not to accumulate a large pile of quotations.

Then work through the dependencies in order:

1. Write the problem independently of a proposed solution. Name the current condition, its consequence and the evidence. Leave an uncertain cause uncertain.
2. Describe the desired future with the people who would use or receive it. Ask what they could see or do differently and how they would know the improvement occurred.
3. List the changes required to make that future possible. Assign responsibility and distinguish prerequisites from work the project will produce.
4. Connect the proposed features and activities to supported benefits. Check the functional effect, the economic implication and what the customer says the result would mean to them.
5. Express that value in language appropriate to the buyer's awareness and existing relationship. Keep the evidence and conditions attached to the claim.
6. Write the offer so that both parties can identify the same scope, responsibilities, terms, acceptance condition and remedy.
7. Check fit in both directions. Resolve missing information or record why the engagement should be narrowed, deferred or declined.
8. Give the buyer a clear decision and next action. Preserve the actual answer, including a refusal, in the handoff.
9. Deliver the useful job, make the result inspectable and record what should change before another commitment is made.

The first pass should expose a decision you can now make and the evidence still needed for a decision you can't. That's a more useful result than a set of completed headings with no effect on the work.

Choose a bounded action and keep the limit visible

A team doesn't have to repair every weak stage at once. It can identify a prerequisite, agree a useful test or correct a missing explanation, then observe what happens. The action should be coherent enough that its outcome informs the next decision.

A form change, for example, needs a stated qualification purpose and a way to examine what happens to suitable enquiries. A new message needs a supported claim and a relevant audience. A technical change needs a real job and evidence of whether that job works. Activity alone won't tell the team whether the diagnosis was useful.

A negative finding can also justify stopping. A buyer may be unable to support the required work. A campaign may exhaust its agreed test without finding an approach worth expanding. A product may need a change in economics before more acquisition is responsible. The method should make those findings easier to act on.

The supplier remains responsible for the commitments it controls. That includes representing the evidence accurately when the result is disappointing, identifying what wasn't learned and refusing to present an uncertain next investment as a guaranteed recovery.

The metal-art request at the beginning could have led directly to a new creative brief. Asking who was actually buying created a different investigation and a different basis for the work. That's the commitment I want to preserve across all nine stages: make the problem clear enough that the next action can be chosen, challenged and changed before the customer pays for the wrong answer.