Behavioral Science Business Strategy That Works

I'm Kurt Schmidt, founder of Schmidt Consulting Group, and I've been saying for years that most organizations confuse motion with progress. Teams crank out tickets, fill Jira boards, run sprints, and measure velocity. And somewhere in all that activity, the actual question, "is this the right thing to build?" gets skipped entirely. Behavioral science business strategy is the discipline that puts that question back at the center, and in my experience working across agencies, B2B services firms, and product organizations, it's the single highest-use shift a leadership team can make.

I recently spent time talking through these ideas with Craig Schumann, a behavioral science practitioner who works at the intersection of organizational behavior, manufacturing, and financial services. What follows is my synthesis of where that conversation landed, filtered through what I've seen hold up in practice.

What Is Behavioral Science Business Strategy, Really?

Behavioral science business strategy is the practice of applying models of human behavior, decision-making, and communication to how an organization discovers what to build, decides what to prioritize, and executes against a vision. It's grounded in the recognition that written documents are a poor medium for building shared understanding of complex ideas, and that groups of people drawing together retain and align on information far better than groups of people reading the same spec.

The foundational insight is simple: strategy describes how a company shows up to compete in a market. It's a decision filter. It's an identity claim. Apple shows up as a premium experience company. Southwest built a market position around accessible, fun air travel. A mid-sized electronics manufacturer probably has a completely different answer, and the mistake most leadership teams make is borrowing a competitor's identity instead of interrogating their own.

Frameworks like the Business Model Canvas give teams a visual starting point for that interrogation. Jobs-to-be-done thinking, popularized by the late Clayton Christensen, pushes the conversation further: who is buying your product, what job are they hiring it to do, and does your value proposition actually match that job? These tools don't replace strategic judgment. They create the conditions for it.

Why Do Organizations Keep Building the Wrong Things?

Every organization I've worked with has the same problem in different clothing. Teams are busy. Busyness reads as value creation. And so the assumption that activity equals progress never gets tested.

The pattern I see most often in product and services organizations is what I'd call specification debt. Teams write extensive documentation, break it into features, break features into user stories, and fill backlogs with tickets. Developers work through those tickets. And somewhere around the third sprint, someone asks whether anyone actually wants the thing being built. The answer is uncomfortable.

Reading long documents is a poor way to build shared understanding of complex systems. It's consistent with decades of cognitive science research on how humans process and retain information. Visual models, especially ones that teams construct together, activate multiple memory systems simultaneously. The act of drawing forces clarification. Disagreements surface in real time. The model becomes a record of the conversation, not just the output.

The analogy I find most useful: if you show someone vacation photos, they say "looks like fun." But if they were with you, they remember the heat, the noise, the specific wrong turn you took on day two. The difference is embodied participation. Whiteboard sessions, whether in a physical room or on a virtual canvas in Miro, create that participation. Documents don't.

I've seen this failure mode play out in enterprise insurance environments, healthcare technology firms, and mid-market agencies. The title structure among the people present determines who talks. The whiteboard marker is a great equalizer. When everyone's drawing, the org chart loses its grip.

How Does Model-Based Discovery Connect to Behavioral Science Business Strategy?

Model-based discovery is the practice of using a deliberate sequence of visual frameworks to move from company vision down to daily execution decisions. The key word is deliberate. The models have to link. Each one should give you enough information to justify the next.

A practical sequence might look like this: start with a business model canvas to articulate the value proposition and customer segments. Move into jobs-to-be-done thinking to pressure-test whether that value proposition matches what customers actually hire the product to do. Build an empathy map to understand the customer's context, frustrations, and goals. From there, a story map (Jeff Patton's story mapping approach works well here) helps teams see the backbone of the user journey before committing to implementation.

What you're doing at each layer is making fewer, better choices. The goal is to pick three, make them visible, and connect them to the daily decisions your teams are making. In organizations running Scrum, that means the 15-minute daily standup should have a traceable line back to the company's strategic vision. If that line doesn't exist, you're not doing strategy. You're doing activity.

I want to name the failure mode here too, because I see it constantly: choosing models because they're interesting rather than because they link to the next decision. If you're using a framework because you want to learn it and it doesn't help you identify what to build next, save it for a training session. Models in a strategic context have one job: help the team make a better choice faster.

This is where thinking intersects with behavioral science. The same discipline that prevents product teams from building the wrong software prevents services firms from launching the wrong offering.

Efficiency Versus Effectiveness: Why the Distinction Matters More Than You Think

This is the framing I find most useful when I'm trying to get a leadership team to slow down and question their assumptions. Efficiency is doing a thing faster and cheaper. Effectiveness is doing the right thing.

Craig Schumann put it in terms I'm going to borrow directly: efficient chemotherapy and effective chemotherapy are not the same thing. Efficient chemo gets administered on schedule at lower cost. Effective chemo treats the specific cancer the specific patient has at the right dosage. Speed and cost savings are irrelevant if you're treating the wrong condition.

In my experience working with B2B services firms, this distinction gets buried under agile language. "We're shipping faster." Great. Are you shipping the right thing? "Our velocity is up 30%." Good. Are those story points solving the customer's actual problem?

The answer usually requires going back upstream to the strategy layer, which is exactly where most teams resist going. It feels like going backward. It feels like admitting the plan was wrong. But testing an assumption early with a lightweight model costs almost nothing compared to building a full feature set against a false premise. I've watched organizations ship entire product lines that customers didn't want because no one was willing to stop and ask whether the core assumption was valid.

This connects directly to pricing strategy for services, because the same organizations that build the wrong product also price their services against the wrong signal. Effectiveness means solving the customer's job. Price follows from that.

How Do You Apply This in Highly Regulated Industries?

Regulated industries use visual models constantly. Architectural blueprints. Electrical wiring diagrams. Medical device schematics. Nobody writes a 300-page document describing where the load-bearing walls go. They draw plans, file plans, and build against plans. Auditors review plans.

Software, for some reason, abandoned that discipline. And in regulated sectors like healthcare and financial services, that abandonment creates real problems. Compliance requirements pile into backlogs as text-heavy user stories. Nobody can trace a code release back to the regulatory requirement that justified it. Audits become archaeological digs through documentation that nobody maintains.

The model-based approach solves this. A visual model can link to a sub-model that links to another sub-model that eventually connects to the code committed to production. The audit trail becomes a diagram. That's actually more defensible to a regulator than a stack of PDFs.

I've seen this play out in behavioral health technology, where the impulse to ask screening questions differently (moving from a rigid two-question clinical instrument to a conversational approach) required actual clinical validation. That work took time. But the outcome was patients describing themselves as feeling like humans rather than checklists, which drove adoption in ways no amount of faster ticket completion could have produced.

The lesson for regulated environments is that behavioral science business strategy doesn't get you around compliance requirements. It helps you do the hard work more visibly, which is exactly what regulators and auditors need to see.

For organizations under 20 people without dedicated product or compliance functions, the overhead of full model-based discovery may genuinely outweigh the benefit. In those cases, a specialist in lean startup validation or a single frameworks consultant is probably a better use of budget than building out this entire system. The discipline scales up better than it scales down.

What's the Right Way to Introduce This Inside an Organization?

Find the people who are already asking good questions. Every large organization has them: the engineer who keeps pushing back on requirements that don't make sense, the product manager who builds empathy maps on a whiteboard in their own notebook, the team that's been using story mapping informally for six months because they figured out it helped. Those people are your pilot.

Don't try to roll this out company-wide. Don't write a policy. Don't announce a new methodology. Find the group that's willing to try something different and help them succeed visibly. When they succeed, the rest of the organization will notice. I've seen this active create genuine FOMO inside enterprise organizations. Teams that were left out start asking to join the next cohort. That's not a dysfunction unique to behavioral science adoption. It happens in every organization that's grown faster than its communication infrastructure. The model-based approach surfaces this early, because getting teams drawing together reveals overlap before millions of dollars get committed. One of the documented benefits of is exactly this: waste reduction through shared visibility.

The deepest behavioral insight Craig Schumann raised is this: children ask questions relentlessly until somewhere around age six, when adults start shutting those questions down. We trade curiosity for efficiency. Organizations do the same thing. The question "why are we doing this?" feels inefficient when there's a sprint to finish. But it's the most valuable question anyone can raise, and behavioral science business strategy is essentially a structured permission system for asking it again.

I covered related thinking on organizational strategy and team alignment in depth on The Schmidt List.

Key Takeaways

• Behavioral science business strategy treats strategy as an identity claim about how a company competes.
• Visual models create shared understanding faster than documents; teams that draw together retain and align on information more effectively than teams that read the same specification.
• Model-based discovery works when models link deliberately: each one should give enough information to justify the next and trace back to company vision.
• The efficiency versus effectiveness distinction is load-bearing; shipping faster against a wrong assumption produces expensive waste at higher velocity.
• Regulated industries already use visual models for compliance; software organizations can apply the same approach to make audit trails more defensible.
• Pilot with willing groups, make their success visible, and let organizational FOMO do the adoption work rather than forcing a top-down methodology rollout.

The question to sit with: if someone asked your team today why you're building what you're building, and traced that answer all the way back to your company's strategic identity, would the line hold? If there's any hesitation in that answer, the models are where to start.