Lesson 7.1: Spotting patterns worth productising
Custom work that repeats belongs in the product, but not every repeat does. Learn the signals, a pattern log, a scoring method and a break-even rule.
By the end of this lesson you will be able to tell which of the things you build for one customer should become part of the company's product, and which should stay custom. You will learn six signals that a pattern is real, a way to separate a genuine pattern from a coincidence, a simple log that turns scattered observations into evidence, a score for ranking candidates and a break-even rule for deciding when to build a feature instead of repeating the custom work. You will see three cases, one of which shows the cost of generalising too early, and use a simulator to find the number of customers at which building the feature wins. This lesson opens Module 7, on going from one customer to many. It builds on the loop in Lesson 1.1, where the last step was to feed what you learned back to the product team, and it answers the question that step raises: what, exactly, should you feed back? No technical background is required.
The forward deployed model exists for a reason that is easy to forget in the middle of a project. A company sends an engineer to one customer so that the product becomes useful there, and also so that the company learns what its product is missing. If the engineer does only the first, the company has bought one satisfied customer and a growing pile of custom work. If the engineer also does the second, each customer makes the product better for the next. The skill of telling a pattern from a one-off is what turns the first situation into the second.
Why this matters
There are three reasons to take productisation seriously, and each is felt differently by the people involved.
For the company, it is leverage. A custom solution serves one customer and costs effort every time it is rebuilt. A product feature serves many, and the effort is spent once. A company that cannot turn repeated custom work into product becomes, in effect, a consultancy: each new customer needs another engineer, and growth requires hiring in proportion.
For the customer, it is durability. A custom piece lives or dies with the engineer who built it, and may be fragile when the product changes. A feature that is part of the product is tested, documented and kept working by the company.
For you, it is time. An engineer who rebuilds the same workaround for every customer has no time to learn new problems. Productising what repeats is what frees you to work on what is new.
There is an opposite risk. A company that turns every customer request into a feature builds a bloated product that fits nobody well. The goal is the right things at the right time, which is the subject of this lesson.
Six signals that a pattern is real
A pattern is something that will keep happening, and is therefore worth building for. The signals below are not a checklist to be ticked mechanically. They are things to notice, and the more of them you see, the stronger the case.
1. It repeats across customers. The same problem, or the same workaround, appears in more than one customer. This is the most important signal. One customer's need might be unique. Two might be a coincidence. Three is a pattern.
2. It repeats across different kinds of customers. A need that appears at a lender, a hospital and a retailer is more general than one that appears at three lenders. The first is a feature for everyone. The second may be a feature for lenders.
3. People ask for it unprompted. When customers raise the need themselves, without being led, it is a real pain. When you have to explain why they should want it, the need may be yours, not theirs.
4. A workaround already exists. If customers are building spreadsheets, scripts or manual routines to fill a gap, the gap is costing them real effort, and the workaround is also a sketch of the solution.
5. It shows up in the sales process. If prospects ask about it before they buy, or lose interest because the product lacks it, it affects the company's growth as well as its customers' convenience.
6. It costs a lot to keep doing by hand. A custom fix that takes a week each time, for each customer, adds up quickly. The larger the repeated cost, the sooner it pays to build once.
The rule of three
A rule of thumb from software engineering helps with timing. In his book on refactoring, which is the practice of improving existing code, Martin Fowler describes a guideline he attributes to Don Roberts, often called the rule of three. The first time you do something, you simply do it. The second time you do something similar, you may wince at the duplication but do it anyway. The third time, you stop and restructure, a point often summarised as "three strikes and you refactor".
The rule was written for code, but it fits productisation well. At the first customer, build the custom piece, and make a note. At the second, notice the repeat and build the custom piece again, but this time write down what is common and what differs. At the third, you have enough evidence to design something general, because you can see what varies between cases and what does not.
The reasoning is about evidence. With one example, you cannot know which parts of the solution are essential and which are accidents of that customer. With two, you can compare. With three, you can see the shape. Building a general feature from one example usually produces something that fits that example, and fits the next one poorly.
Some practitioners find the rule a little dogmatic. They argue that you should prefer a little duplication to the wrong generalisation, which is a fair warning: the cost of a bad abstraction can exceed the cost of copying. The rule is a guide for when to look, not a law that forces a build on the third occurrence.
Essential and accidental similarity
Not every repetition is a pattern. Two things can look alike for reasons that have nothing to do with a shared need. It helps to separate two kinds of similarity.
Essential similarity means the two cases solve the same underlying problem. Three lenders each need to send borrowers a reminder in their own language, with a check on the permitted hours. The details differ, but the need is the same, because it comes from the regulation and the business, and will come from the next lender.
Accidental similarity means the cases look alike on the surface but arise from different causes. Two customers each have a report that groups accounts into two lists. At one, the groups reflect a collections strategy. At the other, they reflect a quirk of an old system. Building a "two-group report" feature for both would give you a general tool with no real general need behind it.
A useful test is to ask why each customer needs the thing, and to see whether the reasons are the same. If the answers are "because of the rules of our regulator", "because borrowers prefer their own language" and "because our callers work in several languages", they share a real cause. If the answers are "because that is how our old system works", they do not.
Predict first: the same workaround, a script that fixes a date format in the nightly file, has now been written for two lender customers. The product manager asks whether to build it into the product. What would you say, and what would you want to know first? Decide before reading on.
The best answer is "not yet, but let us prepare". Two customers is the point to start recording what is common and what differs, not to build. You would want to know why the date formats are mixed in each case: if both come from the same widely used loan system, the issue may be a known behaviour of that system, which is a real pattern worth a proper feature or a standard adapter. If each arises from a different local quirk, the match is accidental, and a general tool would solve neither well. You would also ask how much each fix cost and how many other customers use the same system. The answer is a plan for evidence, not a decision.
The pattern log
Productising well depends on evidence, and evidence depends on a habit: writing observations down when you see them. A pattern log is a simple shared document, kept by you and your colleagues, in which every custom piece, workaround or repeated request is entered as a row. It need not be elaborate. A good row has a few columns.
Field · ExampleWhat was needed · Reminders in the borrower's own language, with the permitted-hours check
Customer and date · Lender A, October
Why they needed it · Regulation on contact hours; borrowers respond more in their own language
What we did · Custom grouping and template logic, 14 days
Workaround cost · About 14 days of engineer time, plus 2 days a quarter to maintain
Other customers with the same need · Lender B (asked in the sales call), Lender C (similar spreadsheet)
Essential or accidental · Essential: comes from regulation and language, common to lenders
Review the log every month or so with the product team. When a row accumulates entries from several customers, it moves to the top of the list. The log also protects you from an error of memory: you may feel that you have built the same thing five times, when the log shows that it was twice, and different.
Ranking candidates
When the log has several candidates, you need a way to choose. A simple score helps, and its main value is to make the discussion concrete. For each candidate, estimate four things.
Frequency. How many customers have this need, or are likely to, over the next year?
Impact. How much does it matter to each of them, in time, money or risk saved?
Generality. How similar is the need across them? Is one feature enough, or would each need something different?
Effort. How much work to build and maintain a proper feature?
A rough score is frequency times impact times generality, divided by effort. The numbers need not be exact. What matters is the ranking: which candidates are frequent, valuable, general and cheap, and which are rare, small, varied and costly. The ones near the top are the first to productise. Those near the bottom stay custom, and that is a legitimate and useful decision.
The path from custom to product
A pattern does not have to jump from a custom script to a polished feature in one step. There is a ladder, and each rung carries a different cost and a different amount of learning.
1. Custom for one customer. You build exactly what that customer needs. Fast, no generality, and no extra cost to anyone else.
2. A reusable internal module. You tidy the custom piece so that you, and your colleagues, can reuse it at the next customer with small changes. It lives in the engineers' toolbox, not in the product.
3. A configurable component. The parts that differ between customers become settings, so a new customer needs configuration and not new code. The language, the hours and the templates become values, and the logic stays fixed.
4. A product feature. The component is built into the product, with tests, documentation, support and a place in the roadmap. The company now owns its upkeep.
Most good productisation climbs the ladder gradually. The reusable module at the second customer teaches you which parts need to be settings. The configurable component at the third shows you how customers use it. The product feature comes when the shape is stable and the demand is clear. Skipping rungs, going from one custom case to a product feature, is how the wrong abstraction is built.
When not to productise
Some things should stay custom, and deciding so is not a failure. Several cases deserve it.
The need is truly specific. It comes from one customer's unique situation and is unlikely to recur.
The similarity is accidental. The cases look alike, but the causes differ.
The market is too small. The need is real but affects a handful of customers, and the cost of maintaining a feature exceeds its value.
It would distort the product. A feature that serves one large customer but complicates the experience for everyone else is a bad trade.
It would be better as configuration or an integration. Sometimes the right answer is a standard way of plugging in the customer's own tool, not a new feature.
The product direction does not fit. The company may have decided not to go in that direction. Respect that, and keep the custom work clean and documented.
In each case, record the decision and the reason in the log. A "no, because" is as valuable as a "yes", since it saves the next person from reopening the question.
Break-even: build once, or repeat?
Even when a pattern is real, the timing matters. Building a feature costs more up front than repeating the custom work once, and pays back only if enough customers use it. The arithmetic is a break-even, in the same spirit as the comparison in Lesson 4.2 between building and buying.
Suppose each custom delivery costs some number of weeks. A product feature costs a larger number of weeks to build, plus some yearly upkeep, and then each customer needs only a small amount of configuration. Over a period, the custom path costs the weeks per delivery times the number of customers. The feature path costs the build, the upkeep and the configuration for each. At some number of customers, the feature becomes cheaper.
The simulator below finds that number. Set the cost of one custom delivery, the cost of building the feature, the yearly upkeep of the feature, the configuration cost per customer with the feature and the number of years. It shows the break-even number of customers and plots the two total costs against the number of customers.
The inputs are your estimates, and the model leaves out the benefits of a feature that are hard to count: customers who are more satisfied, sales that are won, a product that is more coherent. It also leaves out the risk that the feature is built wrongly. The numbers are most useful for starting a conversation with the product team on a common footing.
Try three experiments. First, keep the defaults and read the break-even. Second, double the cost of building the feature and see how many more customers it needs. Third, lower the custom cost to three weeks, which describes a small, quick fix, and see that productising is hardly worth it.
At the defaults, a custom delivery of six weeks, a feature of twenty weeks and four weeks of upkeep a year over two years, with one week of configuration per customer, give a break-even of about 5.6 customers. With six customers in the period, the custom path costs 36 weeks and the feature path 34, a small saving. The message is that the decision depends on the number of customers you really expect, which is why the evidence in the log matters more than the arithmetic. A need seen at three customers that is likely to reach ten justifies the feature. The same need at three customers that is unlikely to reach a fourth does not.
Worked example 1: language-matched reminders
At the lender, the engineer builds custom logic to send reminders in each borrower's own language, with the permitted-hours check. The cost is fourteen days. The engineer enters it in the pattern log, with the reason: regulation on contact hours, and borrowers' language preference.
Two months later, at a second lender, the engineer builds a similar piece, reusing part of the first, in nine days, and adds a row: another lender, the same regulation, a different language mix. The second build shows what differs: the set of languages, the template text and the hours. It also shows what does not: the check against permitted hours and the logic for picking a language.
A third lender asks about the same thing in a sales call. Now the product manager, looking at the log, sees three lenders, an essential cause in regulation and a repeated cost. The team builds a configurable component, with languages, hours and templates as settings. Within the year, five lenders use it, each configured in two days. The first lender's engineer provided the starting design, and the second and third showed which parts to make into settings. Each step produced learning that a single build could not have.
The ladder shows in the effort. The chart compares the days it took to deliver the reminders at each of the first three lenders.
Worked example 2: the bed definition that stayed custom
At the hospital group, the engineer spends five days agreeing a definition of a "free bed" with nurse managers, and writes the logic that applies it, with two exceptions. A product colleague asks whether it should become a feature.
The engineer checks the essential cause. Each hospital's definition came from its own practices: one counts a bed free at discharge, another after cleaning, a third separates beds reserved by the emergency department. These are real, but they are local, and they will differ at the next hospital group. A general "bed definition" feature would be a way of configuring rules that each customer would have to write themselves, with little saving.
The decision is to keep the logic custom and to productise the part that is common: the screen that displays whatever definition is configured, and the check that its bed counts agree with a manual count. The log records both decisions with reasons. The engineer's judgement, to productise the display and keep the definition custom, saved the company from building a rules tool for a need that did not recur.
Worked example 3: the abstraction built too soon
At a retailer, an engineer writes a clever piece of logic that combines a forecast with stock levels to suggest orders. A product team hears about it, and, excited by the results, builds a general "order suggestion engine" with many options, based on this one example.
The first new customer, a pharmacy chain, finds that the engine does not fit. Its ordering depends on expiry dates and regulated storage, which the retailer's case had never involved. The options the team built are mostly irrelevant, and the one that matters is missing. The pharmacy needs six weeks of custom work on top of the engine, and the engine carries ongoing upkeep for features used by one customer.
A review notes what happened: the product was built from a single example, with no log of other customers and no check of whether the retailer's need was essential or particular to its situation. The cost was months of effort and a feature that few customers want. A better path would have waited for a second and third case. The rule of three, in Fowler's phrase, is a defence against exactly this: with one example, you do not yet know what the general version should be.
Working with customers on it
Productising touches the customer, since you are about to take something built for them and offer it to others. Two things deserve care.
Agree who owns what. A custom piece built under a contract may belong to the customer, or to your company, or be shared. Check the terms with your own company's contracts team before you reuse it, and never reuse a customer's confidential data or logic without permission.
Tell the customer. A customer whose work becomes part of the product is often pleased, particularly if their name appears on the roadmap or they get early access. A customer who learns later that their custom work was turned into a product without a word may feel used.
Common mistakes
Productising from one example. Wait for the second and third, and record what varies.
Mistaking coincidence for a pattern. Ask why each customer needs it, and see whether the causes are the same.
Never productising. Repeating custom work forever makes the company a consultancy. Keep a log, and review it.
Skipping rungs. Move from custom, to a reusable module, to a configurable component, to a feature, as evidence grows.
Relying on memory. Write each observation in the pattern log as it happens.
Ignoring the cost of upkeep. A feature has to be maintained for as long as customers use it.
Forgetting the "no". Record decisions not to productise, with the reasons.
Reusing without permission. Check ownership and confidentiality before you reuse a customer's work.
Key takeaways
The forward deployed model works when each customer makes the product better for the next. The skill is telling a pattern from a one-off.
Six signals show a pattern: it repeats across customers and across kinds of customers, people ask unprompted, a workaround exists, it appears in sales and it is costly by hand.
Use the rule of three as a guide for when to look: do it, tolerate it, then generalise at the third occurrence, remembering that the wrong abstraction can cost more than copying.
Separate essential similarity, a shared cause, from accidental similarity. Ask why each customer needs the thing.
Keep a pattern log, rank candidates by frequency, impact and generality over effort, and climb the ladder: custom, reusable module, configurable component, product feature.
Break-even depends on how many customers you really expect. Some things should stay custom, and recording why is as useful as recording what to build.
Check yourself
1. Name three of the six signals that a pattern is real.
Any three of: it repeats across customers, it repeats across different kinds of customers, customers ask for it unprompted, a workaround already exists, it shows up in the sales process, it costs a lot by hand.
2. What is the rule of three, and why is it useful for productisation?
Do it the first time, tolerate the duplication the second time, and restructure at the third. It reflects that you need enough examples to see what is essential and what varies before you generalise.
3. What is the difference between essential and accidental similarity?
Essential similarity means the cases solve the same underlying problem for the same reasons. Accidental similarity means they look alike on the surface but come from different causes.
4. A custom delivery costs 8 weeks. The feature costs 30 weeks to build, 5 weeks a year to maintain over 2 years, and 2 weeks to configure per customer. What is the break-even number of customers?
(30 + 5 × 2) ÷ (8 − 2) = 40 ÷ 6, about 6.7 customers.
5. Why might you decide not to productise a real pattern?
The need may be specific to one customer, the similarity accidental, the market too small, the feature a distortion of the product, or better handled as configuration or an integration.
Try this
This exercise takes about forty minutes and starts a pattern log. Use your own work, or a series of customers or colleagues you know, even informally.
1. List at least five things you have built, fixed or answered more than once, for different customers, colleagues or clients.
2. For each, write the row: what was needed, who, why, what you did, what it cost and who else has the same need.
3. For each repeat, ask why each person needed it, and mark it essential or accidental, with a reason.
4. Score each candidate for frequency, impact and generality, and estimate the effort. Rank them.
5. For the top candidate, place it on the ladder: custom, reusable module, configurable component or feature. Write what the next rung would involve.
6. Use the simulator with your own estimates to find the break-even number of customers.
7. Write the "no" for one candidate: why it should stay custom.
8. Write who you would tell, and what you would check about ownership, before reusing the work.
A good result is a pattern log with at least five rows, a ranked list, one candidate placed on the ladder, a break-even estimate and one recorded "no". It is the habit that turns a series of projects into a growing product.
Sources
[Rule of three (computer programming)](https://en.wikipedia.org/wiki/Ruleofthree(computerprogramming)), Wikipedia, with other summaries. Used for the rule attributed to Don Roberts and popularised by Martin Fowler's book on refactoring: do it once, tolerate it the second time and refactor the third, and for the caution from practitioners that the wrong abstraction can cost more than duplication. I read secondary summaries, not the book.
The distinction between essential and accidental similarity follows a common practitioner framing found in the same summaries, explained here in the author's own words.
The three cases, the pattern log, the customer counts and the simulator's figures are the author's illustrations for teaching, not data from real companies. The six signals, the scoring method and the ladder are practical guidance written for this lesson, not industry standards.
Tags: Forward Deployed Engineer Productisation Product strategy Customer patterns Software engineering