For decades, software development has mirrored the construction industry — a manpower-heavy model where effort, hierarchy, and sequencing define how value is created. But that model is no longer working. Not for users. Not for businesses. And certainly not for the kind of dynamic, value-led experiences today’s market demands.
Let’s break it down.
Building software like a Construction Project
The traditional process of building software is eerily similar to a construction site. First, you collect “requirements” from stakeholders. Then, a budget is discussed, features are scoped, and everything is put into a phased roadmap. That roadmap is handed to product managers, who work with execution teams to begin “building.”
The metaphor continues:
You lay the foundation (the backend and data architecture).
You raise the structural skeleton (modules, features, tech stacks).
You install the fixtures (pages, flows, user controls).
And only then somewhere towards the very end — you call in design for making it “creative”.
At this point the design teams attempt to improve the product by applying design process. Teams organize features into an information architecture, then bundle them into menus, apply usability fixes, and run some user testing to improve comprehension. The assumption? This methodology of bringing value to end users will ensure that everything is there: a long list of features, ergonomics, and technology.
why then would the users not love it?
But more and more, this process ends with a hard truth:
The product doesn’t work.
Users don’t engage. Drop-offs are high. Features are not discovered. Friction is everywhere.
What happens next is even worse: teams start patch-fixing the product, tweaking labels & features, and applying another round of “lipstick” — without questioning whether the product value, architecture, behavior model, or service logic is even relevant anymore.
This entire model is built on two faulty assumptions:
#1 That users are motivated to go find value hidden inside your structure
#2 That features + IA + Easy UI = a successful product
Neither holds true today. Users aren’t navigating mega menus. They’re not exploring tabs hoping to discover something useful. Whether it’s consumer apps or enterprise tools, they expect value to find them — immediately, intelligently, and repeatedly.
Products Are No Longer Menu Structures. They’re Living Systems of Value
The way people engage with digital products has fundamentally changed. The old IA-based approach — “let’s organize features and serve them through menus” — is no longer relevant.
Today’s users don’t want structure. They want service.
They expect the product to sense context, surface value, and adapt to their needs in real time. This is true even in complex domains — from productivity tools to trading platforms. The expectation is the same: “show me what I need, when I need it, enabling me to do what i want.”
And this is where the traditional software building process breaks down completely. Because we’re still treating product delivery like a cataloging exercise — build the system, then arrange everything into folders and flows.
What we should be doing is designing living products that:
Start with a powerful zero state
Use data to understand user context from the first click
Surface relevant value, information, working surface quickly — before users go hunting
Progressively disclose & sell deeper features and upsell paths over time
Build a clear case for users to do more in the tool/surface
Lead users organically toward monetization
Keeps building in extensible value to ensure retention
Feel like they evolve with the user, not against them
In this model, the product sells itself. It grows, adapts, and justifies its presence in the user’s life — not through frictionless UI, but through value delivered in flow.
And no, this can’t be achieved by “improving the IA” or running another round of user testing on pre-defined flows. That’s experience optimization. What we need is value-led product architecture.
VCPB — A New Methodology: Building Products around Value & Behavior
The traditional software development process — structured like a construction site — was built for a world that no longer exists. It assumes we can gather all requirements, phase out delivery, and organize features like building blocks. At best, we optimize user flows toward the end. At worst, we mistake infrastructure for impact.
What we need now is an entirely new methodology — one that starts not with features, menus or screens, but with value. One that is shaped around behavior, powered by lean tech, and continuously evolves to serve both the business and the user.
Here’s how it needs to work:
Value: Define the Business Value
It is key to understand that businesses are built around value that they can offer their customers. The business needs to deliver this value and needs a vehicle for the same. The confluence of the value and monetization creates the business viability.
Service Strategy: Deliver Value Across the Service Experience
To create monetization around the value, a service experience strategy has to be created. This strategy aims at creating various ‘key Desired Behaviors’ (KDBs) from customers across the service lifecycle. To summarize to create monetization on the business value, we need to generate some KDBs across the service lifecycle. The ‘moments of connect’ where KDBs intersect the service lifecycle, we get touchpoints that will deliver that value. The entire purpose of creating a touchpoint is to create a KDB and deliver value.
Behavior Strategy: Create KDBs
At each touchpoint, build mechanisms that trigger and reinforce key desired behaviors. Apply ergonomics and psychology at play to influence customers. At each of those touchpoints, you design the logic, flow, and content to trigger and reinforce real behavior. This is not about “delight” or “clarity.” It’s about getting users to do what matters — to them and to the business.
Interaction Modality: match vehicle to touchpoint
Define how the touchpoint behavior strategy would be delivered. What surfaces, UI, interaction modality would be needed. Don’t assume full-screen flows. Explore WhatsApp, embedded PWAs, voice, or smart nudges.
This is where most teams fail. They assume the solution is always an app, a dashboard, or a full-screen interface. But users today interact with products across a dozen surfaces — and in shorter bursts. Design for the surface/interaction that best serves the behavior.
Enable with Technology: Data+AI+ROI
The system must feel intelligent — reacting to behavior, tailoring context, and adapting value dynamically. Look at available data, process and anticipate with AI, look at other AI or relevant technologies that would make ROI sense.
We no longer need massive teams to build feature stacks. Today, lean teams can build agentic systems — architectures that use data and AI to dynamically adapt, orchestrate workflows, and deliver value with precision.
Instead of stacking features, you’re orchestrating value delivery.
Instead of static product roadmaps, you’re building systems that learn and respond.
AI is not a bolt-on. It’s part of the core delivery engine.
Test for Real Behaviors
Not UI mocks. Not polished Figma files. Real, functioning prototypes that let you observe behavior in the wild. This is critical as the traditional software building process is aimed at improving comprehension, but we need to look at how to create real KDBs.
Conclusion: Shift from Feature Menu to Value base product Building
It’s critical to understand how the golden thread connects:
from value → to key behaviors (KDBs) → to touchpoints → to interaction modality → to tech enablement.
This isn’t just a more evolved way to build products.
It’s a complete inversion of how the industry has traditionally operated.
The SDLC — and everything it inspired — was built for a world of stable requirements, feature stacking, linear delivery, and motivated users. That world no longer exists.
Today, if your product doesn’t trigger the right behaviors, it doesn’t survive.
We’re long past the point where structure-first, manpower-driven builds make sense.
We can’t afford to treat software like a construction site — stacking features, layering flows, and painting design on top.
We need a system built around value creation, not volume delivery.
One that starts with the outcome, not the roadmap.
That operates in flow, not phases.
That learns, adapts, and sells itself — in real time.
We’re not building digital infrastructure anymore.
We’re building dynamic value systems that must work — fast, fluid, and alive.
And anything less will be forgotten.
I help companies reimagine how they deliver value across their entire digital ecosystem — from strategy to execution, product to service experience. Currently building this vision at www.Futurris.com
— Amber Krishan
From Stacking Features to Shaping Value: A New Product Building Model was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.
