Many things in life have growing pains. Throughout my career I have almost always found myself in companies going through a moment of expansion, change or innovation, and with teams trying to respond to a reality different from the one they were organized for. Innovation carries an inherent cost: it demands learning, letting go of certain certainties and accepting that a useful solution may stop being enough.

Often, the solutions that product managers and business owners create are designed for a specific market size, volume of use or production capacity. Within those conditions they work well. The problem appears when we read that result as proof that they will work the same way in any other scenario, as if growing were simply a matter of repeating what we already know how to do.

For me, talking about what breaks when you scale means talking about what we will have to rebuild or redefine. It does not mean everything was a mistake, or that we must start from zero. It means recognizing the limits of the body that brought us here and deciding how to build one capable of carrying what comes next, without losing what makes our product worth existing.

Size is designed too

Ceramics workshop with shelves full of unfired pieces waiting their turn in front of a closed kiln — Figure 8.1 — Useful capacity belongs to the whole system: pieces wait at the slowest station.

In industrial design we learn that production volume is a design constraint. We do not choose the same process to make twenty parts as to make twenty thousand. The upfront investment, the available materials, the tolerances, the setup time and the way quality is controlled all change. A procedure that is excellent for a short run can become a poor decision when you try to repeat it thousands of times.

I know industrial designers whose work could well be described as product or portfolio management: they decide what to produce, for whom, with what resources and under what commercial promise. Some have faced more demand than they expected and discovered that selling more did not solve their problems. The workshop could not deliver on time, capital was tied up in materials, or rework ate the margin of every additional order.

A machine can make forming a part cheaper and, at the same time, demand an investment that is only recovered with sustained volume. If demand lasts less than that payback, the promised unit cost never materializes. It can also happen that the new equipment produces more than the kiln, the finishing area or distribution can handle. Useful capacity belongs to the whole system; buying capacity at one station does not guarantee more of it at the end of the line.

Something similar happens in technology. A product can solve a small business’s problem very well and need a deep rebuild to operate inside an enterprise. If I say, for example, that 70% of the product would have to be redone, that figure illustrates the possible magnitude of the change; it is not an industry statistic. What matters is recognizing that a business case validated at one scale does not automatically validate another.

More than traffic changes

Top-down view of a workshop table with ceramic pieces of very different shapes, each with a blank tag, while a pair of hands moves one of them — Figure 8.2 — More orders, more different cases: the exception handled by hand stops being a solution once it repeats.

An enterprise customer does not always mean thousands of additional users. Sometimes it means a few users with different permissions, integration with legacy systems, traceability of decisions, service commitments and an operation that cannot stop when the founder goes on vacation. Volume matters, but so do the diversity of cases, their criticality and the consequences of getting it wrong.

Picture an ordering platform where one person resolves exceptions by hand. During the pilot, that intervention can be a reasonable way to learn. When hundreds of exceptions arrive every day, that person becomes a critical dependency, responses slow down and the cost of serving each order changes. The system may still be up, but the service promise is already failing.

That is why it pays to separate quantitative growth from a change in conditions. More transactions may demand capacity; more markets may demand new rules; more enterprise customers may demand data isolation and different ways of contracting. If we confuse those needs, we end up buying servers to solve a coordination problem, or hiring people to compensate for an architectural decision that needs revisiting.

The first conversation about scale should pin down what we expect to grow, over what period and with what mix of demand. It should include peak hours, expensive tasks, third-party dependencies and exceptions, not just average volume. Saying “we need to be ready for ten times more” is an aspiration. Describing ten times more of what, at what quality and at what cost, starts to become a product specification.

Growth can change the promise

An artisan's hands shaping a clay piece on a wheel, with finger marks visible — Figure 8.3 — One-off piece: the process is part of the value.

A short series of handmade vessels on a shelf, alike but not identical — Figure 8.4 — Short series: variations the customer recognizes.

Rows of identical ceramic pieces on pallets in a production plant — Figure 8.5 — Volume line: another promise, another price, another finish.

A handmade clay piece can carry value that is inseparable from its process. The artisan’s trace, the variations between objects and the time devoted to each finish are part of what someone decides to buy. We can find a way to produce more pieces, but we cannot assume they will automatically keep the same meaning for the person who chooses them.

Consider a collection brand such as Merakia, used here as an example of the decision an artisanal brand might face, not as a claim about its operations or plans. If its proposition depends on small series and handwork, transforming all of its production to meet mass demand could weaken it. Another possibility would be to develop a higher-volume line with a promise of its own, with clearly differentiated materials, prices and finishes.

That decision belongs to the portfolio: determining which part of the business keeps its exclusivity and which part seeks to widen access. Lines can share a design language without pretending to be equivalent. The trouble starts when an industrial piece is offered with the same story of craftsmanship that justified the value of an artisanal one, in the hope that the customer will not notice the difference.

“The ability to grow does not oblige us to pursue every possible growth.”

At a logistics company I worked on a B2B version of its product. The company did not see it as profitable to leave its segment to reach the volume that market required.

I do not consider that, in itself, to have been a bad decision. Recognizing that another segment demands a different operation, and deciding not to take it on, is also product management.

When the economics stop holding

Packing station with a finished plate beside boxes, protective material and a box holding a returned, broken piece — Figure 8.6 — The cost of a piece does not end in the workshop: packing, support and returns also grow with volume.

Before assessing whether the platform will withstand the demand, we need to understand whether the business can sustain it. Infrastructure cost is only one part. Customer onboarding, support, errors, reconciliation, returns and coordination work grow too. Some items increase per unit; others appear all at once when we need another shift, a new specialty or broader service coverage.

Let me propose an illustrative exercise. An operation charges 100 monetary units per order and spends 60 on variable costs, so it keeps 40 to contribute to its fixed costs. In a new segment, the commercial discount lowers revenue to 85, while integrations and customer service raise the variable cost to 75. Now 10 remain. It would take four times as many orders to earn the same total contribution, before paying the additional fixed costs of that expansion. The figures are made up; the question they reveal is real.

The economic assessment should compare scenarios of demand, customer mix and cost per completed outcome. It is worth looking at what an order delivered correctly costs, not just what it costs to receive a request. If the product depends on customer credit, inventory or payment terms, we must also check when money goes out and when it comes back. A business can show an accounting margin and still run out of resources to finance its next cycle.

The conclusion may be to invest, change prices, limit customization, separate lines or postpone the expansion. There is no professional obligation to turn every product into a mass operation. There is a responsibility to understand what commitments we are accepting when we promise to do so.

Examine before you rebuild

Inspection bench with calipers, aligned test tiles and a thermocouple beside a plate being measured by a pair of hands — Figure 8.7 — Examine before rebuilding: measure what exists to know what to keep.

An infrastructure assessment should start from the journey that produces value. On a logistics platform we could follow a shipment from quote to delivery confirmation and locate the dependencies at each step. That map lets us tell a failure visible on screen apart from a problem building up in a queue, a database or an external provider.

For a structured review, AWS Well-Architected offers a framework and a tool for examining workloads, recording risks and tracking improvements.¹ The point is not a decorative score but turning each finding into a decision with an owner, evidence and a date. A diagnosis without an intervention plan only describes the risk we have already agreed to keep running.

Load testing complements that review. Tools such as k6 make it possible to rehearse normal load, sudden spikes, sustained pressure and capacity limits.² Before running them we need a representative mix of operations, realistically sized data and success criteria. Repeatedly requesting a lightweight page does not show that a system can process complex orders while reconciling payments.

Observability lets us understand what happens during those tests and during operation. OpenTelemetry provides instrumentation for signals such as metrics, traces and logs.³ SRE practice highlights latency, traffic, errors and saturation.⁴ For product, those signals make sense when they are tied to a promise: how many users completed their task, how long they waited and what the failure cost them.

Table 8.1 — Assessment questions before scaling

Question	Evidence we need	Decision it enables
What load can we handle at acceptable quality?	Tests with a realistic mix, errors and p95/p99 latencies, the percentiles that show the experience of the slowest responses	Set a validated capacity and the conditions for expanding it
Where does work pile up?	Traces, queue age, busy connections and dependency times	Address the bottleneck before expanding the rest
What happens if a dependency fails?	Controlled tests of unavailability, recovery and retries	Design degradation, limits and protection against duplicates
Can we recover data and operations?	Rehearsed restores; agreed recovery-time and acceptable data-loss objectives	Fix recovery before taking on greater criticality
What does completing one unit of value cost?	Technology, service and rework costs per outcome and per segment	Revisit price, scope or the viability of the expansion
Is the enterprise environment ready?	Tests of permissions, tenant isolation and traceability	Close the gaps before onboarding the new segment

Not every test should run in production. A test that can cause downtime requires a controlled environment and scope. Nor should we pick thresholds because they appear in a slide deck: a two-second response can be acceptable for one query and far too slow for another task. The limit has to come from use and from the promise, and be validated with evidence.

The mold does not replace the workshop

Open resin mold for ceramic casting with a freshly demolded, still unfired piece of tableware — Figure 8.8 — The machine changes the forming; drying, firing and finishing still call for judgment.

Now picture a porcelain workshop. To keep the parallel precise, I will talk about pressure casting, a tableware manufacturing technique that introduces fluid ceramic material into molds; it should not be confused with plastic injection. There are traditional casting systems with plaster molds and high-pressure systems with resin molds.⁵ Adding machinery changes the forming, but it does not eliminate the product’s other stages.

Before buying it, we need to check how the slip, drying, firing and finishing behave within the chosen process. A repeatable mold does not, by itself, correct a later deformation or decide which variations are acceptable for the collection. A machine also introduces new tasks: setup, maintenance, parameter control and response to deviations.

The artisan can keep adding value in painting, detail, selection and acceptance criteria. Part of their knowledge will have to become samples, instructions or observable limits so others can reproduce it. Another part may stay deliberately manual because it sustains the identity of the piece. The decision should not depend on whether an activity is old or modern, but on what it contributes and how it behaves at the new scale.

The matrix below is a working proposal for discussing the transition, not a universal recipe. The same question applies to a ceramics line, a digital product or a service: what function does this activity serve, and how will we show that the change preserves its value?

Table 8.2 — Keep, standardize, automate, redesign or retire

Decision	In the porcelain workshop	In the digital product or service	Evidence of acceptance
Keep	Hand finishes that define the collection	Specialist judgment and handling of sensitive cases	Quality the customer recognizes, at a sustainable capacity
Standardize	Reference samples and preparation parameters	Business rules, data contracts and procedures	Less variation without erasing valuable differences
Automate	Repetitive forming compatible with the mold	Repeatable validations and low-judgment tasks	Less time and fewer errors, including the cost of supervision
Redesign	Drying and firing flow for the new cadence	Architecture, queues, permissions and cross-team coordination	The full flow validated under the target load
Retire	An adjustment that compensated for a limitation now removed	Double entry or an approval that no longer protects anything	Removal tested without loss of control or value

Learning doesn’t happen all at once

When the process changes, people do not reach the same point at the same time. Some want to experiment early; others need to see results, practice or understand what risk they are taking on. The adoption curve associated with Everett Rogers makes it possible to represent different moments of taking up an innovation. Its classic categories distinguish innovators, early adopters, early majority, late majority and laggards.⁶

Its use for a leader lies in remembering that a demo excites some people and does not meet everyone’s needs. A pilot with volunteers can help uncover possibilities, but it does not show that the rest of the operation is ready. Whoever needs stability before adopting has reasons worth knowing, especially if they will answer for the consequences of a failure.

Nor does the bell describe each person’s productivity or emotional experience. There is no mandatory sequence of denial, resistance and acceptance here. Someone may understand the purpose of the change and lack the time to learn; someone else may master the tool and disagree, with good arguments, with how it is meant to be used. Treating those situations as if they were the same makes them harder to solve.

We can use a second image to think about how support shapes the process. The two bells below represent hypothetical scenarios of time to competent use: one spread out and late, another more concentrated and early. They are not results of a study, nor a promise that training will always produce that shape. They serve to frame a hypothesis we must test against the team’s practice.

Supporting the transition

Prosci’s ADKAR model organizes individual change around awareness of the need, desire to take part, knowledge, ability and reinforcement.⁷ It can help us separate problems that tend to get lumped together under the word resistance. If someone does not understand why the process is changing, another technical training session may solve nothing. If they understand and want to take part but lack access to a practice environment, insisting on their attitude would be unfair.

As my own application of that logic, I propose short conversations paired with an observable task. Asking someone to complete a representative case, explain their decisions and know whom to turn to when there is an exception yields more evidence than asking whether they “get it”. Support should include protected time, sufficient documentation, low-risk practice and feedback on the work done.

The learning curve is different from the adoption bell. It describes how a capability or a result changes with practice. During a transition, performance may dip temporarily because processes coexist, questions increase and the tool is not yet mastered. There may also be no dip, or there may be one the team never recovers from if the change is poorly designed. The drawing does not guarantee the outcome.

To manage that uncertainty we need a baseline, an observation period and criteria for intervening. If rework keeps growing or service deteriorates, it is time to review the workload, the support and the method itself. Calling any problem a “growing pain” does not entitle us to normalize wear and tear indefinitely.

“We no longer ask why the information is entered twice; we teach the newcomer where to do the second entry.”

Closeness to a product lets us see details no one else notices, but it can also make its problems invisible. That is what I mean by workshop blindness: we have lived with a limitation for so long that we have built it into our idea of how things should work.

Accumulated knowledge deserves respect, even though not every procedure that comes with it should be kept. One way to regain perspective is to watch someone new perform a task without clearing every obstacle for them in advance. Another is to walk through the process with a customer or a colleague from another discipline and ask them to describe where they wait, what they do not understand and what effort produces no visible result.

Value stream mapping helps separate effective work, waiting, approvals and rework. A failure mode analysis lets us ask what could go wrong, what the consequences would be and what controls exist. Both can be done on a concrete journey and updated with evidence. Their usefulness disappears if they turn into long workshops that produce diagrams but no change to the operation.

Inviting other eyes does not mean disparaging the team that built the product. It works well in pairs: someone who knows its history and someone who can question its assumptions. The first explains why an exception exists; the second asks whether that reason still holds. That exchange makes it possible to tell valuable knowledge apart from habit.

Measuring the team as it grows

Workshop wall tool board with painted outlines; most filled and two outlines empty — Figure 8.12 — A capability map looks like a shadow board: you can see what is there and what is missing.

Assessing the team for a new scale requires starting with the system of work. A person can look slow because they handle all the delicate reviews, or because they receive the cases nobody else knows how to solve. If we only measure closed tasks, we may punish the judgment that protects quality and reward whoever hands the hard work to others.

In software teams, DORA offers delivery performance metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.⁸ They should be used to understand and improve the performance of a team or service in its context, not as a leaderboard of individuals. Reading them is complete only alongside product outcomes and working conditions.

For physical or service teams, the same intention calls for other measures: units accepted first time, total lead time, returns, effective resolution and pending workload. An increase in parts made matters little if rejects grow even faster. Likewise, an increase in support responses does not show that customers are solving their problems.

Individual assessment also needs evidence of competencies, conversations and real learning opportunities. I propose a descriptive scale per skill: needs support, acts autonomously, or can teach and improve the process. I would not add it up into a single score. What interests me is identifying which capability is missing, where a dependency exists and how it can be covered.

Table 8.3 — Capabilities for the new scale

Capability	Observable evidence	Possible support or decision
Understanding the whole system	Connects their work to earlier and later stages and to customer outcomes	Short rotations and joint reviews of journeys
Learning and transferring knowledge	Solves a new case and leaves an explanation someone else can use	Supported practice and time to document
Sustaining quality under volume	Spots deviations and applies consistent criteria, without hiding exceptions	Shared samples, tests and acceptance limits
Working with other specialties	Makes dependencies explicit, negotiates priorities and asks for help before getting blocked	Clear responsibilities and agreements between teams
Operating automation and AI with judgment	Recognizes limits, verifies results and knows when to stop or escalate a case	Representative evaluations and risk-based supervision
Protecting continuity	Can cover for others or be covered without the service depending on their constant presence	Backup pairs, procedures and handover drills

Hiring for the next stage

Two adjacent workbenches: one heavily used, marked by years of craft, and a new one with tools laid out and a folded apron — Figure 8.13 — Hiring for the next stage also means preparing the place where that person will learn.

A capability matrix may reveal that we need to train the people already here, reorganize responsibilities or hire a specialty that does not yet exist. Those decisions are not equivalent. Changing the org chart does not create knowledge; hiring someone experienced does not fix an operation in which no one has the authority to decide.

Before opening a role, I would write down which scale problem we expect to solve and what evidence would show that person’s contribution. If the problem is reliability, we need the ability to design and operate with failures. If it is enterprise onboarding, we may need integration, implementation or change management. The job title should come after understanding the need.

I would also look for a willingness to teach, listen and keep what works. Someone arriving with experience from a much larger company can bring perspective, but can also introduce unnecessary complexity. Relevant experience includes recognizing when a practice helps and when its cost would exceed the problem it is meant to solve.

The transition must have capacity assigned to it. Asking the same team to run operations, learn a platform, migrate data and keep its delivery speed intact amounts to promising the same output while we replace every machine in the workshop. Reducing work in progress and reserving learning time are planning decisions, not concessions to a lack of commitment.

Bound, observe, transform, validate

A sequence repeated at each increment of scale, not phases that close for good.

1
Bound
Agree on segment, volume and promise.
2
Observe
Gather the baseline.
3
Transform
Address the bottleneck.
4
Validate
Compare against the promise.

I propose organizing the work in four moments. Their purpose is to avoid a giant rebuild based solely on expected demand.

Bound. We agree on the segment, the volume, the conditions and the promise we want to sustain. We also define what we are not willing to sacrifice: a certain quality, the handling of sensitive cases, an artisanal identity or a cost ceiling. That conversation brings product, business and operations together before a technical solution becomes a commercial commitment.

Observe. We gather the economic, technical and human baseline.

Transform. We choose the bottleneck that limits the whole and decide what to keep, standardize, automate, redesign or retire. We test the change in a bounded scope, with owners and a way back to a workable state if the result does not meet what was agreed.

Validate. We compare against the promise and the baseline. The new capability must demonstrate quality, economic viability and sustainability for the team. Only then do we widen the scope. Growing in increments lets us discover which of our assumptions were right before committing the rest of the business.

AI enters the workshop

Plain industrial robotic arm demolding a raw piece while a pair of hands inspects the surface of another piece under a lamp — Figure 8.14 — Automation frees time, but checking the surface still takes judgment.

AI makes this discussion especially visible because it changes the effort needed to produce certain results. It can help draft, code, classify information or prepare alternatives. However, a reduction in generation time does not in itself amount to a better product. We still need to know whether the result is useful, what errors it introduces and how much work it takes to verify.

The comparison with porcelain is useful. Automating the forming can free up time for design, finishing or customer care, but that value does not appear on its own: someone has to decide where to invest the freed capacity. Something similar happens with AI. If we produce more proposals than we can evaluate, we may only have moved the bottleneck from execution to review.

I would assess its adoption by comparing the previous process with a pilot on representative cases. I would measure time to an accepted result, errors that reach the user, rework, full cost and the need for human intervention. I would include difficult cases, not only those where the tool shines. If generation takes less time but correcting and verifying take more, the improvement has not yet been shown.

I would not treat the number of prompts, the volume of text or the lines of code generated as a measure of value. What interests me is what the user can now do, with what confidence and at what cost. That also requires clarity about the data used, the limits of action and who answers when a decision affects the customer.

The value we choose to keep

Hands brush-painting a blue band on a mold-formed porcelain plate — Figure 8.15 — The piece leaves the mold; the judgment stays in someone's hands.

Much of what is valuable in a technology product lives in the idea, the concept, the market and the way we approach it. Execution work is indispensable, but its difficulty does not guarantee that what it produces is valuable. We can spend months building something nobody needs, or use a tool that reduces the effort and spend that time understanding the problem better.

This does not make technical quality irrelevant. An attractive concept that loses information or delivers inconsistent results also destroys trust. Quality comes from joining intention and execution: understanding what deserves to be done and sustaining it with an operation that delivers. Automation should help us take care of that relationship, not disguise that we have not defined it.

Like the artisan who keeps painting and refining details on an industrially formed piece, people can focus their judgment where the difference matters. Sometimes it will be a visible finish; at other times, a difficult conversation, a well-handled exception or the decision not to automate a moment that calls for human company. Warmth also needs to be designed and given time within the operation.

For me, dedication and passion make sense when they turn into care another person can perceive. We do not need to claim that no machine will ever produce something beautiful in order to defend that human responsibility. We are the ones who decide what promise we make, what we accept as good enough and how we respond when the product falls short.

Rebuilding with what we learned

Kintsugi, the Japanese repair of ceramics with lacquer and finishes that may include gold, offers a powerful image for thinking about this transition.⁹ The seam does not try to erase the piece’s history entirely: it makes it visible and builds it into its new form. What interests me is that possibility of carrying on without pretending that what came before never existed.

The metaphor has a limit: a repair does not automatically make any object stronger, and not every architecture deserves to be kept. In product, future strength has to be demonstrated. There are components we will have to replace, processes worth retiring and decisions we can no longer sustain. What we do not need to throw away is all the knowledge accumulated along with them.

Our gold may be a well-understood business rule, a relationship of trust, a quality practice or the memory of a mistake we do not want to repeat. Keeping that learning lets us build something different without turning renewal into an act of amnesia. The valuable seam lies in connecting what we learned with what we now need to do.

When I say that nothing breaks forever, I mean that possibility of carrying on, not an obligation to rescue every piece. If we decide to grow, we will have to revisit infrastructure, architecture, quality processes, team and mindset. Perhaps the hardest work is accepting that what made us competent at one stage will not be enough at the next. But if we understand what value deserves to remain and demonstrate a more capable way of sustaining it, the break will have been part of the learning with which we build a better product.

REFERENCES

Amazon Web Services — AWS Well-Architected. Framework for reviewing workloads and risks. ↩
Grafana Labs — Load test types — k6. Differences between load, stress, soak, spike and breakpoint tests. ↩
OpenTelemetry — What is OpenTelemetry?. Instrumentation and observability signals. ↩
Google — The Site Reliability Workbook: Monitoring. Service monitoring and operational signals. ↩
SAMA / SACMI — Casting systems for producing ceramic tableware. Traditional and high-pressure casting for ceramic tableware; a manufacturer source. ↩
University of Oklahoma — Diffusion of Innovation Theory. Educational summary of Everett Rogers’ model and its adopter categories; a secondary source, not an experimental evaluation of teams. ↩
Prosci — The Prosci ADKAR Model. Components of individual change. ↩
DORA — DORA’s software delivery performance metrics. Definitions and contextual use of delivery metrics. ↩
Joan B Mirviss LTD — Golden Renewal: Understanding Kintsugi Repair. Conversation with lacquer and ceramics specialists, July 22, 2021. ↩

Editorial note — The professional experiences come from the author’s own account. The economic example, the matrices and the four-moment method are illustrative proposals of this chapter; they are not presented as validated instruments. Figures 8.10 and 8.11 are schematic and contain no observed data. The mention of Merakia is a hypothetical decision example, not a description of the brand.

What Breaks When You Scale a Product