Practice

Software Studies — A Collaborative Framework for Product-Focused R&D

A peer-to-peer reflection on structuring inquiry, extending patterns of thought, and deepening the way we design and build software.

This page outlines a practice I’ve used to reason about product design and engineering over the long arc of my career. It isn’t meant as doctrine. It’s an invitation — a structure for leaders who already have a solid conceptual foundation and want to explore the edges of that thinking.

The ideas here don’t replace existing models; they sit alongside them.

The intent is simple:
to offer a set of abstractions and artifacts that extend how we understand and communicate the work.

A Shared Philosophy for Product-Focused Engineering

Most engineering leaders have developed their own internal frameworks for navigating ambiguity, forming strategy, and shaping product direction. This practice builds on that shared intuition by making a few principles explicit:

1. Understanding is cumulative — and articulation accelerates it.

Teams often sense the patterns long before they have language for them. Giving names to these patterns — through models, diagrams, ontologies, or classifications — sharpens collective intelligence and speeds alignment.

2. Research and development are not a sequence, but a conversation.

We move back and forth between exploration and construction constantly. Treating these as complementary spaces (rather than phases) makes room for deeper insight and better decisions.

3. Engineering and design are two perspectives on the same responsibility.

Most leaders already operate this way, even if their org charts don’t acknowledge it. This practice simply formalizes the idea that architects, engineers, and designers shape experience, information, behavior, and structure together.

4. Artifacts are how teams think collectively.

Whether diagrams, studies, models, or prototypes — artifacts create a shared field of view. They make reasoning visible. They give teams something to push against, refine, and extend.

These principles likely echo your own experience; the practice just puts clearer structure around them.

A Model for Reasoning About Software

Software as Knowledge Media

This framework treats software as the fusion of knowledge and medium — a way of organizing what users want to accomplish into a structured, interactive form.

It organizes our thinking into four lenses:

1. Agent

User goals, processes, constraints.
The origin point for every meaningful product decision.

2. Experience (Scope & Strategy)

How we define the purpose of a system and the plan to achieve it.
Not UX in the narrow sense, but contextual reasoning.

3. Form (Media)

How the system is perceived and navigated:

• Skeleton: information architecture, interaction framework
• Surface: interface, aesthetics, sensory design

4. Function (Software)

How the system behaves internally:

• Structure: data models, relationships, information logic
• System: workflows, logic, operational behavior

As leaders, we work across all four — often implicitly. The model gives us a formal vocabulary for the thinking we already do.

A Dual-Track R&D Practice

This practice intentionally separates the mental space of understanding from the mental space of building, because each demands different cognitive modes.

But the purpose isn’t separation — it’s elasticity.
To let teams move fluidly between inquiry and application with a common structure.

Track 1 — Research (Exploration & Sensemaking)

A space for expanding the problem, gathering evidence, and forming the language that guides development.

Activities:

• Survey and select topics
• Pose study questions
• Form research statements
• Investigate and analyze
• Synthesize insights
• Critique with structured evaluation

Artifacts:

• Studies and research briefs
• Conceptual models
• Vocabulary maps (ontologies, taxonomies)
• Information architecture sketches
• Aggregated notes and curated resources

Research produces clarity — but more importantly, it produces language.
Language becomes the substrate for strategy.

Track 2 — Development (Design & Construction)

A space for applying what was learned and shaping it into form and function.

Activities:

• Define objectives, constraints, and strategic direction
• Model data and structure
• Design workflows, interactions, and information patterns
• Build prototypes and architectural drafts
• Assemble systems and components
• Evaluate and refine

Artifacts:

• Requirements, briefs, and problem definitions
• Data models and classifications
• Interaction and IA models
• Wireframes, prototypes, workflows
• Architecture diagrams
• Code, utilities, services
• Evaluation summaries

Development turns shared understanding into something tangible, critique-able, and extendable.

Language as an Instrument of Invention

One idea worth foregrounding — because engineers feel it more than they discuss it — is how much of our work involves creating language.

Not for abstraction’s sake, but because building new systems often requires new conceptual boundaries:

• differentiating concepts that didn’t need differentiating before,
• naming patterns that were previously unnamed,
• reframing behaviors in ways that make them designable,
• constructing ontologies that reveal structure,
• forming taxonomies that clarify the domain.

When we expand vocabulary, we expand what the team is capable of perceiving and building.

A robust R&D practice doesn’t just produce systems.
It produces the language that makes systems possible.

For many practitioners — especially seasoned engineers — this is the most meaningful part of the work. It engages curiosity, fosters insight, and restores a sense of creative ownership that is often lost in purely execution-driven environments.

A Practice Meant to Be Expanded

This framework shapes how I approach architecture, product reasoning, and engineering leadership:

• clarifying ambiguous problem spaces,
• aligning collaborators through structured artifacts,
• and extending the conceptual tools we use to make decisions.

It’s not meant to be prescriptive. It’s meant to be extendable — something we can refine together as peers who have seen similar challenges from different angles.

If it adds language or structure that complements how you already think, then it has served its purpose.

Footnote

This page was produced with assistance from ChatGPT.
Read the behind-the-scenes write-up →