Lesson 7.2: Feeding product and engineering
Customer needs reach the product team as evidence or as noise. Learn the field brief, how to argue with data, contribute code well and close the loop.
By the end of this lesson you will be able to turn what you learn in the field into something the product and engineering teams can act on. You will learn the parts of a good field brief, the difference between a request and a problem, a simple way to score and compare requests, how to work with the people who decide the roadmap, how to contribute code to the product without creating trouble, and how to tell the customer what happened to their request. You will see three cases, one of which shows how a loud request was ignored while a quiet one succeeded, and use a simulator to see how evidence changes a request's priority. This lesson follows 7.1, where you learned which patterns to productise. Here you learn how to persuade the people who build the product to do it. You do not need a technical background.
The last step of the loop in Lesson 1.1 was "feed back", and it is the step most often done badly. An engineer in the field sees a problem every day. A product team sees hundreds of requests from dozens of sources, each pressing, each arriving with a different degree of certainty. In that flood, the field's feedback either stands out because it is clear, specific and backed by evidence, or it drowns because it arrives as an anecdote with an adjective attached: "The customer really needs this." You are the most informed witness of what customers need, and the quality of your testimony decides whether it changes anything.
Two kinds of feedback
It helps to see the difference between the feedback that is ignored and the feedback that moves a roadmap.
Weak feedback sounds like this: "Lender A wants a dashboard." "Customers are asking for AI." "This is a big blocker for us." It reports a request, or an emotion, but not the problem behind it, the evidence or the scale. A product manager who receives it has to guess what is really needed, how many people need it and how it compares with everything else. Most such messages are acknowledged and filed.
Strong feedback sounds like this: "Collections teams at three lenders spend about two hours a day deciding which accounts to call first, because the product shows accounts in one flat list. At Lender A, I measured it for a week: 41 per cent of calls went to accounts that paid within seven days anyway. All three built spreadsheets to sort the list. A sorting rule in the product would remove the spreadsheet and, from the pilot, raised first-week repayment by five points. I estimate three weeks of work." It gives a problem, a number, a pattern, a workaround, evidence of the effect and an estimate. A product manager can act on it.
The difference is not eloquence. It is that the strong version contains information the product team does not have and cannot easily get, because you were there. That is the real value of the field.
The anatomy of a field brief
A field brief is a short document, about a page, that carries one problem from the field to the product team. It has a fixed shape, much like the one-page plan of Lesson 2.4, so that the reader knows where to look. A useful brief has seven parts.
1. The problem, in one sentence. Not the feature, but what is going wrong, for whom and at what cost. Use the form from Lesson 2.1: who cannot do what, because of what, costing how much.
2. Who has it, and how many. The customers or users affected, today and likely over the next year, with a note of how you know. Link to the pattern log from Lesson 7.1.
3. Evidence. The facts that show the problem is real: measurements, quotes in the users' own words, a count from the log, a screenshot, a short recording. Evidence turns an opinion into information.
4. What happens today. The workaround, what it costs in time and money, and what risks it carries. This shows the size of the pain and sketches a solution.
5. What success would look like. The outcome you want and a number that would show it, which is the metric thinking of Lesson 2.3 applied to the product. Describe the outcome, and offer a solution as a suggestion rather than a demand.
6. Options and effort. Two or three ways the product could address it, from small to large, with your rough estimate and the trade-offs. This shows you understand that engineering time is limited.
7. What you need and by when. A decision, a conversation or a place on the roadmap, and the date by which a customer is waiting. Be honest about urgency, since false urgency spends the credibility you will need later.
Lead with the problem, not the solution
A common and costly mistake is to arrive with a solution. "We need a sorting rule that takes five fields and applies a threshold" may be right, and it also closes off the conversation. The product team may know a better way, may have related work underway or may see that the problem is wider than the field's view. If you present the problem first and offer your idea as one option, they can engage with the problem as colleagues.
Presenting the problem first also protects you against being wrong. The solution you imagined at one customer may be unsuitable for the next, as the example in Lesson 7.1 of the order suggestion engine showed. A well-stated problem survives a change of solution.
There is a respectful middle path. Describe the problem fully, say what you did for this customer, and say plainly that you are not wedded to it: "This is what worked in the pilot. I would be glad to hear whether a different approach would serve more customers."
Predict first: a customer's senior executive tells you she wants a new reporting feature within a month, and she has mentioned it to your company's chief executive. The product team says it is not on the roadmap and the quarter is full. What do you do first, and what do you not do? Decide before reading on.
Start by finding out what the executive is trying to achieve, which is the underlying problem, using the questions in Lesson 2.1. The report may be one way to meet a need that could be met in another way, such as an existing report or a small custom view. Then gather evidence on how many other customers have the same need. With that, you can offer the executive options, and take a short brief to the product team, so that the discussion is about a problem and not a demand. What you should not do is promise the executive that it will be built, as Lesson 6.2 warned, or go around the product team without telling them. A promise you cannot back damages trust on both sides, and bypassing people costs the goodwill you need for the next request.
Comparing requests fairly
Product teams must choose among far more requests than they can build, and they use scoring schemes to compare them. One widely used scheme multiplies the number of people reached, the impact on each, and the team's confidence in the estimates, and divides by the effort. It is often called RICE, after the four words reach, impact, confidence and effort. The numbers are rough, and the scheme is not a formula for decisions. Its value is that it makes the factors explicit.
Learn to speak this language. For each request you carry to the product team, work out the four numbers as honestly as you can.
Reach. How many customers or users will this affect in a given period? Your pattern log gives you this.
Impact. How much will it matter to each? A common scale runs from a minimal effect to a massive one, with numbers such as a quarter, a half, one, two and three.
Confidence. How sure are you of your estimates of reach and impact? This is where evidence enters. A request backed by a measurement and three customers deserves a higher confidence than one resting on a single conversation.
Effort. How much work, in person-months, from the product and engineering team? Ask them. If you do not know, say so, and give a range.
The score rises with reach, impact and confidence, and falls with effort. The most important lesson is in the third factor. Many field requests have high reach and high impact in the engineer's mind, and low confidence in the product manager's, because the evidence is missing. Every piece of evidence you add, a measurement, a customer count or a recording, raises confidence and with it the score.
The simulator below shows this. Set the reach, impact, confidence and effort. It computes the score and compares it with a typical item on a roadmap, which you can set. It plots the score as effort grows and as confidence rises.
The scheme is a simplification. It is silent on strategy, risk and dependencies, which a product manager must weigh. Use it as a way of asking better questions of your own request: how many, how much, how sure and how big.
Try three experiments. First, keep the defaults and read the score. Second, raise confidence from 60 to 90 per cent, as if you had added a measurement and two more customers, and see what evidence is worth. Third, double the effort and see how the score halves, which is why offering a smaller first slice often wins.
At the defaults, ten customers, an impact of two, 60 per cent confidence and three person-months give a score of 4, a little above the typical item at 3. Raise the confidence to 90 per cent and the score is 6. Halve the effort and it is 8. These are the two levers a field engineer controls: evidence and the size of the first step.
Working with product and engineering people
The people on the product and engineering side are colleagues with a different view and different pressures. Treating them well makes your requests easier to hear.
Understand their constraints. They are balancing many customers, a roadmap, technical debt and limited people. A "no" or a "later" is rarely a judgement on your customer. Ask what they are working on and why.
Bring them to the customer. Invite a product manager or an engineer to a demo or a working session. Hearing a user describe a problem, in their own words, is worth a page of brief. Many product teams are keen to do this and are rarely asked.
Respect their time. Send a short brief, not a long message. Use the same format each time. Do not send urgent requests that are not.
Make it easy to say yes. Offer a small first slice, a pilot with one customer, a feature behind a switch or a design you have already tried. A request for a small, testable step is far easier to approve than a request for a big commitment.
Offer to help. Volunteer to test, to write the customer-facing documentation, to share your pilot data or to join a design review. Engineers value people who reduce their work.
Share the outcome. When something you flagged ships, tell the team how it worked for the customer. Good news is rare in their inbox and it builds goodwill.
Disagree in the open. If you believe a decision is wrong, say so, with evidence, to the people involved. Do not complain about product to the customer, and do not complain about the customer to product.
Contributing code
Forward deployed engineers often write code that could belong in the product. At Palantir, for example, engineers in the field role say they often contribute code back to the core product, when a missing feature or a bug stands between a customer and its outcome. The same engineers stress that it must be coordinated with the product team, that larger requests have to be checked against the roadmap and that changes are reviewed by the team that owns the code.
That description fits any company. A few rules make contributions welcome.
Talk first. Before you write anything substantial, tell the owning team what you plan to do and why. They may already be working on it, or may know a pitfall.
Follow their standards. Use their style, tests, documentation and review process. A contribution that ignores them creates work for others.
Keep it small. A small, well-tested change is reviewed quickly. A large one waits.
Include tests and a note. Show that it works and explain what it changes, and what it does not.
Separate customer-specific parts. Do not carry a customer's names, data or rules into the product. Keep what is specific to one customer in your custom layer.
Accept their decisions. The owners may rewrite your change, narrow it or decline it. That is their right, since they will maintain it. Thank them, and keep your custom version if you must.
Hand over ownership. Once merged, the product team owns it. Do not expect to be called when it breaks, and help them if you are.
A contribution that goes well saves the company a build and teaches the product team about the field. One that goes badly, a large, untested change dropped in without warning, costs goodwill that takes a long time to recover.
Closing the loop with the customer
A step that is often forgotten is to tell the customer what happened. A request that goes into a void leaves the customer wondering whether anyone listened. Closing the loop takes a few minutes and has a disproportionate effect.
Whatever the answer is, say it plainly, and with the reasons. If the request was accepted: "Your request is on the roadmap for next quarter. I cannot promise the date, and I will tell you when it moves." If it was declined: "The product team decided not to build this, because only a few customers need it. Here is what we can do instead." If it is being considered: "It is being evaluated against other work. I will update you by the end of the month."
Be careful about dates. Roadmaps change, and a date that you pass on as a promise becomes a commitment that you do not control, as in Lesson 6.2. Say "planned" or "under consideration", and say what could change it.
Show the customer the effect of their input when it ships. A customer who sees that their feedback shaped the product becomes a stronger advocate, and a better source of the next piece of feedback.
Worked example 1: the brief that became a feature
The engineer who built the sorting rule at the lender writes a one-page brief for the product team, using the seven parts. The problem: callers spend about two hours a day deciding whom to call, because the product shows a flat list. Who has it: three lenders, with two more asking in sales calls. Evidence: a week of measurement at one lender, showing that 41 per cent of calls went to accounts that would have paid anyway, and the pilot's five-point gain. What happens today: three spreadsheets, each maintained by one person. Success: the share of first-band accounts paying within seven days, plus callers spending less time sorting. Options: a configurable sort rule (three weeks), a rules builder (three months) and a full scoring model (a year). The engineer recommends the first, because it covers the three cases in the log.
The product manager reads it in four minutes and asks two questions. The score, with reach 5, impact 2, confidence 80 per cent and effort 0.75 person-months, is about 10.7, well above a typical item. The sort rule is built in the following quarter, and the engineer is invited to review the design. A page, and a clear problem with numbers, did what weeks of informal mentions could not.
Offering options from small to large helped the sorting-rule brief, because the product manager could see the smallest step that covered the cases in the log. The chart shows the three options and their effort.
Worked example 2: the loud request and the quiet one
Two requests reach the product team from the field in the same month. The first, from an account executive, is that a prospect, a large bank, "needs an AI assistant", with a note that the deal depends on it. There is no problem statement, no count of other customers and no evidence. The second, from a forward deployed engineer, is a short brief: five customers have asked for alerts when a nightly file is late, each with a homemade script, and it has been the cause of two incidents. It has a count, a cost and a small estimate of two weeks.
The loud one is acknowledged and gets a long meeting, which ends with questions nobody can answer. The quiet one is accepted within a week and shipped in a month. Six months later, customers mention the alert as a reason for renewing. The lesson is not that big requests are bad. It is that a request with a problem, a number and a small first step is easy to act on, and the loudest voice is not the best argument.
Worked example 3: a contribution done well
An engineer finds that the product's message sender does not check permitted contact hours, which every lender customer must do. The custom check has been written three times. The engineer decides to contribute it.
First, the engineer messages the owning team: "I have written this check three times, for three lenders. I would like to contribute a version that reads the permitted hours from configuration. May I draft it, and who should review?" The team lead replies that a similar feature is planned, and suggests a different design that would also serve a use case in another product. The engineer follows it, writes the change with tests and documentation, keeps the lenders' specific hours in their configuration and has it reviewed by two people. It merges within two weeks, and the engineer removes the custom versions from the three lenders over the following month.
The result is a feature, three fewer custom pieces to maintain and a product team that is glad to hear from the field. The engineer did four small things right: talked first, followed their standards, kept it small and let them shape the design.
Common mistakes
Passing on requests without evidence. Add a problem, a count, a measurement and the cost of the workaround.
Leading with the solution. State the problem first, and offer your idea as one option.
Inflating urgency. Be honest about dates. False urgency spends credibility.
Promising the customer the roadmap. Say "planned" or "under consideration", and say what could change it.
Going around the product team. Bring them into the conversation, with the customer if possible.
Contributing without talking first. Check what the owning team is doing, and follow their standards.
Carrying customer specifics into the product. Keep names, data and special rules in your custom layer.
Forgetting to close the loop. Tell the customer what happened and why, and show them the effect when it ships.
Complaining sideways. Disagree in the open, with evidence, with the people involved.
Key takeaways
The field's feedback moves a roadmap when it carries what the product team cannot see: a problem, a count, evidence and the cost of the workaround.
Write a one-page field brief with seven parts: the problem, who has it, evidence, what happens today, what success looks like, options and effort, and what you need and by when.
Lead with the problem and offer solutions as options. A well-stated problem survives a change of solution.
Learn to score requests by reach, impact, confidence and effort. Evidence raises confidence, and a smaller first slice lowers effort.
Treat product and engineering people as colleagues: understand their constraints, bring them to customers, make it easy to say yes and share the outcome.
Contribute code by talking first, following their standards, keeping changes small and separating customer specifics. Close the loop with the customer, plainly and without promising dates.
Check yourself
1. Name the seven parts of a field brief.
The problem, who has it and how many, evidence, what happens today, what success looks like, options and effort, and what you need and by when.
2. Why present the problem before the solution?
The product team may know a better approach or related work, and a well-stated problem survives a change of solution, while a solution tied to one customer may not fit the next.
3. In the scoring scheme, which factor does evidence mainly raise?
Confidence. A measurement, a customer count or a recording makes the estimates of reach and impact more believable.
4. Reach 20 customers, impact 1, confidence 80 per cent, effort 4 person-months. What is the score?
20 × 1 × 0.8 ÷ 4 = 4.
5. A customer asks what happened to the feature they requested, which was declined. What do you say?
Say plainly that it was declined and give the reason, for example that few customers need it, then offer what you can do instead. Do not leave it unanswered.
Try this
This exercise takes about forty minutes and gives you a field brief. Use a real problem you have seen more than once, or an imagined one from a project.
1. Write the problem in one sentence in the form: who cannot do what, because of what, costing how much.
2. List who has it and how many, and how you know. Add the pattern log entries if you have them.
3. Collect three pieces of evidence: a measurement, a quote in a user's own words and a count or screenshot.
4. Write what happens today, with the workaround and what it costs.
5. Write the outcome you want and a metric that would show it.
6. Write two or three options from small to large, each with a rough effort.
7. Score the request for reach, impact, confidence and effort, and use the simulator to see how it compares with a typical item. Note what evidence would raise the confidence.
8. Write what you need and by when, and cut the whole brief to one page. Ask a colleague who does not know the project to say, after reading it, what the problem is and what you want.
A good result is a one-page brief with all seven parts, a score and a list of the evidence you would add. It is the document that turns an observation from the field into something the company can act on.
Sources
[Dev versus Delta: Demystifying engineering roles at Palantir](https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87), Palantir engineering blog, 8 April 2019. Used for the point that engineers in the field role often contribute code to the core product, that this should be coordinated with the product team and that larger feature requests need to be validated against their roadmap. These are company staff describing their own practice.
The scoring scheme of reach, impact, confidence and effort is widely used by product teams. It is explained here in the author's own words, and its numbers are rough estimates.
The three cases, the brief, the customer counts and the simulator's figures are the author's illustrations for teaching, not data from real companies. The field brief format and the rules for contributing code are practical guidance written for this lesson, not industry standards.
Tags: Forward Deployed Engineer Product feedback Prioritisation Engineering collaboration Customer insight