Archive

Value streams

From Operational Value Streams to Prod•gnosis

Connecting Allen Ward and Bob Marshall’s Product Development Philosophies

A thoughtful exploration of two complementary approaches to transforming product development

Introduction

In the world of product development theory, two complementary approaches stand out for their innovative thinking about how organisations might tackle the creation of new products: Dr Allen Ward’s approach, born of many years researching the Toyota approach, and my own approach, which I’ve named Prod•gnosis

While Dr. Ward’s work on operational value streams emerged from his extensive study of Toyota’s product development system, Prod•gnosis builds upon and extends his ideas into a comprehensive framework focused on organisational transformation for better product development, reduced costs, and more appealing products.

This post explores the connections between these two approaches and how, together, they offer a powerful lens for fundamentally rethinking product development.

The Foundation: Allen Ward’s Operational Value Streams

Allen Ward’s core insight, which has become a cornerstone of lean product development e.g. TPDS, is elegantly simple yet profound:

“The aim of development is, in fact, the creation of profitable operational value streams.”

An operational value stream (OVS) represents the set of steps that deliver a product or service directly to the customer (and others). This includes activities like manufacturing a product, fulfilling an order, providing a loan, or delivering a professional service.

Ward’s work, drawing from his decade of direct research at Toyota, showed that effective product development isn’t just about designing isolated products. Rather, it’s about designing the entire system through which those products will be manufactured, shipped, sold, and serviced. This holistic approach explains much of Toyota’s success in bringing new products to market quickly and profitably.

Ward emphasised that creating profitable operational value streams requires:

  1. A “whole product” approach that involves every area of the business
  2. Knowledge creation as the central activity of product development
  3. The use of tools like trade-off curves for decision-making and teaching
  4. Systematic waste elimination throughout the development process

Prod•gnosis: Building on Ward’s Foundation

I’m delighted to acknowledge my intellectual debt to Dr. Ward. In my writings on Prod•gnosis, I directly reference Dr. Ward’s influence, adopting his view of “business as a collection of operational value streams.”

I define Prod•gnosis (a portmanteau of “Product”, and “Gnosis” meaning knowledge) as a specific approach to product development that places the creation of operational value streams at its centre. However, Prod•gnosis extends Dr. Ward’s thinking in several notable ways:

The Product Development Value Stream (PDVS)

Prod•gnosis introduces the concept of a dedicated “Product Development Value Stream” (PDVS) as a distinct organisational capability responsible for creating and instantiating operational value streams. I previously wrote:

“I suggest the most effective place for software development is in the ‘Product Development Value Stream’ (PDVS for short) – that part of the organisation which is responsible for creating each and every operational value stream.”

This represents a significant organisational shift from traditional department-based structures.

Challenging IT’s Role in Product Development

Prod•gnosis particularly questions the conventional role of IT departments in product development. Prod•gnosis argues that software development does not belong in IT departments but instead is much more effective when situated within the Product Development Value Stream:

“If we accept that the IT department is poorly suited to play the central role in a Prod•gnosis-oriented organisation, and that it is ill-suited to house or oversee software development (for a number of reasons), then where should software development ‘sit’ in an organisation?”

The answer is clear: within the PDVS, where it can directly contribute to creating operational value streams.

Incremental Implementation

Prod•gnosis proposes a “Lean Startup-like approach” to implementing operational value streams:

“I’m thinking more in terms of a Lean Startup-like approach – instantiating version 0.1 of the operational value stream as early as possible, conducting experiments with its operation in delivering an MVP (even before making its 1.0 product line available to buying customers), and through e.g. kaizen by either the product development or – the few, early – operational value stream folks (or both in collaboration), incrementally modifying, augmenting and elaborating it until the point of the 1.0 launch, and beyond.”

This represents a pragmatic approach to putting Dr. Ward’s principles into practice.

Key Points of Alignment

Despite their different emphases, Ward and Prod•gnosis’ approaches share significant philosophical alignment:

1. Value Stream-Centric View

Both view business fundamentally as a series of operational value streams, with product development focused on creating and improving these streams rather than just designing isolated products.

2. Whole Product Approach

Both emphasise the importance of involving all aspects of a business in product development. Prod•gnosis references Toyota’s “Big Rooms” (Obeya), which Ward studied extensively, as an example of effective cross-functional collaboration.

3. Systems Thinking

Both reject piecemeal improvements and advocate for fundamental shifts in organisational perspective. As Ward wrote and Prod•gnosis quotes: “Change will occur when the majority of people in the organisation have learned to see things in a new way.”

And see also: Organisational Psychotherapy as a means to help organisations see things in a new way.

4. Flow Focus

Both emphasise the importance of flow in product development, with Prod•gnosis particularly focused on aspects like flow rate, lead time, cycle time, and process cycle efficiency – both of the PVDS and the OVSs.

Practical Applications of the Combined Approach

Organisations seeking to apply these ideas might consider:

  1. Creating a dedicated Product Development Value Stream responsible for designing and implementing operational value streams (a.k.a. new products)
  2. Removing software development from IT departments and placing it within the PDVS
  3. Adopting a “whole product” approach that brings together all business functions in the service of product development
  4. Implementing early versions of operational value streams viw the PVDS, and then iteratively improving them
  5. Measuring and optimising flow through the product development process

Getting There: Transitioning to Prod•gnosis

Moving from conventional product development approaches to a Prod•gnosis model represents a significant organisational transformation. As Prod•gnosis acknowledges,

“getting there from here is the real challenge”

The transition requires more than just structural or process changes—it demands a fundamental shift in collective mindset.

The Challenge of Organisational Transformation

The Lean literature is replete with stories of organisations failing to move from vertical silos to horizontal value streams. Prod•gnosis presents additional challenges by proposing to remove software development from IT departments and create an entirely new organisational capability (the PDVS).

As Ward wisely noted and Prod•gnosis quotes:

“Change will occur when the majority of people in the organisation have learned to see things in a new way.”

This insight highlights that sustainable transformation depends on shifting collective beliefs rather than merely implementing new processes.

Organisational Psychotherapy as a Path Forward

In Organisational Psychotherapy I propose as a methodical approach to shifting collective assumptions and beliefs. As an Organisational Psychotherapist, I apply psychotherapy techniques not just to individuals but to entire organisations.

OP recognises that organisations, like individuals, operate based on deep-seated assumptions and beliefs—i.e. “memeplexes” These collective mental models determine how an organisation functions and often unconsciously resist change. And see my book “Hearts over Diamonds” (Marshall, 2018) for more in-depth discusion of memeplexes.

Organisational Psychotherapy works by:

  1. Helping organisations become aware of their current collective beliefs (surfacing)
  2. Examining how these beliefs serve or hinder effectiveness (reflecting)
  3. Supporting the organisation in exploring new, more productive mental models
  4. Facilitating the adoption of these new models

For organisations seeking to move toward Prod•gnosis, this might involve addressing fundamental beliefs about:

  • The nature and purpose of product development
  • The relationship between software development and IT
  • The definition of “whole product”
  • The organisation’s relationship with customers and all the Folks That Matter™
  • How value flows through the organisation

As Prod•gnosis emphasises, this isn’t a quick fix. The transformation to Prod•gnosis represents a significant evolution in how organisations think about and structure product development. The journey requires patience, persistence, and a willingness to examine and change foundational assumptions about how product development might work significantly better.

Conclusion

The synthesis of Allen Ward’s operational value stream concept and Prod•gnosis offers a powerful framework for rethinking product development. By viewing product development as the creation of complete operational value streams and establishing organisational structures that support this perspective, organisations can potentially achieve the kind of rapid, profitable product development that Toyota has demonstrated.

As more organisations struggle with digital transformation and the ever-increasing importance of software in product development, these two complementary approaches may provide a valuable roadmap for fundamentally rethinking how products are developed and brought to market.


What are your thoughts on the operational value stream approach to product development? Have you seen examples of it in practice? I’d love for you to share your experiences in the comments below.

Further Reading

For those interested in exploring these concepts further, the following resources might provide some useful insights:

Ward, A. C. (2007). Lean product and process development. Cambridge, MA: Lean Enterprise Institute.

Sobek, D. K., & Ward, A. C. (2014). Lean product and process development (2nd ed.). Cambridge, MA: Lean Enterprise Institute.

Lean Enterprise Institute. (2021). Lean product and process development: Introduction. https://www.lean.org/wp-content/uploads/2021/01/lean-product-and-process-development-introduction.pdf

Marshall, B. (2012, August 4). Prod•gnosis in a nutshell. Think Different. https://flowchainsensei.wordpress.com/2012/08/04/prodgnosis-in-a-nutshell/

Marshall, B. (2013, February 12). Product development flow. Think Different. https://flowchainsensei.wordpress.com/2013/02/12/product-development-flow/

Kennedy, M. N. (2003). Product development for the lean enterprise: Why Toyota’s system is four times more productive and how you can implement it. Richmond, VA: Oaklea Press.

Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Redondo Beach, CA: Celeritas Publishing.

Marshall, R.W. (2018). Hearts over diamonds: Serving business and society through organisational psychotherapy. Falling Blossoms

Prod•gnosis: Nothing New, Just Better Organised

Every organisation creates new operational value streams when launching products—they just do it chaotically. When a new product line emerges, companies cobble together resources across departments, form temporary project teams, and somehow bring products to market. The Prod•gnosis model simply formalises what already happens, but in a structured way that eliminates the chaos and the costs.

The Core Insight: Acknowledge What You’re Already Doing

Organisations are already operating with two distinct value streams, though almost never by design:

  1. Ad hoc Product Development: Temporary cross-functional efforts that somehow create new products
  2. Operational Value Streams: Systems that eventually deliver and support those products

The problem isn’t that companies don’t create new operational value streams—they do. But they do it inconsistently, reactively, implicitly, and often painfully.

The Current Reality: Chaotic Creation

Look carefully at how your organisation actually launches new products:

  • Marketing creates requirements in isolation
  • Product teams prioritise based on limited technical understanding
  • Engineering builds what they interpret from incomplete specifications
  • Operations scrambles to ship and support whatever gets delivered to them
  • Project managers desperately try to coordinate across departmental boundaries

This chaotic approach somehow delivers products, but at tremendous cost: missed deadlines (cost of delay), technical debt, market misalignment (cost of focus), and burned-out teams. You’re already creating operational value streams—just in the most painful way possible.

From Chaos to Capability: The PDVS Advantage

A Product Development Value Stream (PVDS) simply formalises what you’re already attempting to do, transforming a chaotic process into a permanent ever-improving capability:

  • Instead of forming temporary project teams, maintain dedicated cross-functional groups
  • Rather than reinventing processes with each new product, develop institutional expertise
  • Replace improvised handoffs with designed collaboration
  • Transform one-off learning into compounding organisational knowledge
  • Make schedules highly dependable through e.g. set-based concurrent engineering

You’re already paying the cost of creating new operational value streams—adopting the Prod•gnosis perspective just ensures you get full value from that effort.

Making the Implicit Explicit

To transform your chaotic product creation into a structured capability:

  1. Identify who’s actually creating your new operational value streams today
  2. Formalise these cross-functional collaborations into permanent teams
  3. Move software development from IT into this product development capability
  4. Replace departmental handoffs with integrated teamwork
  5. Capture the knowledge that’s currently lost between product launches

The Bottom Line

Your organisation is already creating new operational value streams—just inefficiently, and without realising it. Prod•gnosis doesn’t ask you to do anything fundamentally new. It simply recognises and organises what you’re already doing, transforming chaos into capability.

The cost is organisational change. The benefit is turning an expensive, unpredictable process into a strategic advantage. Nothing new, just better organised.

Prod•gnosis: Revolutionising Product Development

A Radical New Paradigm for Creating Market-Leading Products

The Challenge

In boardrooms across the globe, executives are grappling with an uncomfortable truth: traditional product development is failing them.

Have you noticed these warning signs in your organisation?

  • Software teams working in isolation, disconnected from the commercial realities of your market
  • IT departments wielding disproportionate influence over development priorities
  • Products launching months—sometimes years—behind schedule
  • Development budgets routinely exceeded, with decreasing returns on investment
  • Cross-functional collaboration reduced to frustrating handoffs and email chains
  • Competitors consistently beating you to market with innovative offerings

The consequences are dire: market opportunities missed, customer loyalty eroded, and competitive advantage surrendered. All while your expenditure on product development continues to rise.

You’ve likely attempted various remedies: agile methodologies, design thinking workshops, innovation labs, digital transformation programmes. Yet fundamental problems persist because these solutions address symptoms rather than the underlying organisational disease.

The root issue isn’t your people or their capabilities. It’s a product development model that was designed for a different era—one where functional specialisation and departmental silos made sense. That era has ended, yet its organisational structures persist.

The Cost of Inaction

What happens if you continue with your current approach?

In the short term, you’ll see incremental improvement from your latest change management initiative, giving the illusion of progress. Teams will adapt to new approaches and practices while maintaining old mindsets and organisational boundaries.

But the trajectory remains unchanged:

  • Development cycles that stretch far beyond market windows
  • Products that arrive too late to capture premium market positions
  • Talented specialists who become increasingly frustrated by organisational barriers
  • Innovation that happens despite your structure, not because of it
  • A widening gap between your offerings and what customers truly value

The most concerning cost isn’t measured in Pounds or Dollars or Euros but in opportunity. While your organisation continues to wrestle with structural inefficiencies, more nimble competitors will seize the market positions that should have been yours.

Consider the cautionary tales of Nokia, Kodak, and Blackberry—market leaders who couldn’t adapt their product development approaches quickly enough to changing market conditions. Their valuable assets, talented people, and strong brands weren’t enough to save them from organisational structures that couldn’t deliver innovation at the pace the market demanded.

If these trends continue unchecked in your organisation, where will you be in three years? Five years? Will you still be a market leader, or will you be fighting for relevance? Or even survival?

The Revolutionary Core: Dual Value Streams!

At the heart of Prod•gnosis lies its most revolutionary concept—a fundamental reimagining of how organisations structure themselves for product development:

The Breakthrough: Two Distinct but Interconnected Value Streams

The Prod•gnosis model introduces a radically different organisational structure built around two types of value streams:

  1. Product Development Value Stream (PDVS): A permanent organisational capability dedicated to creating new operational value streams. This is not a project team assembled for a single product, nor a functional department like R&D. It’s a persistent capability that specialises in the complex work of bringing new products a.k.a. operational value streams from concept to market readiness.
  2. Operational Value Streams: Dedicated streams for each product line that handle everything needed to deliver, support, and evolve that product for customers. Each operational value stream is custom-designed by the PDVS to optimally support its specific product.

This dual structure creates a powerful organisational engine: the PDVS continuously designs and launches new operational value streams, each perfectly tailored to its specific product. As these operational value streams mature, they feedback insights to the PDVS, creating a virtuous cycle of learning and improvement.

Why This Dual Structure Changes Everything

This isn’t simply reorganising boxes on an org chart—it’s a fundamental rethinking of how value creation works:

  1. Specialisation in Creation vs. Operation: The PDVS develops deep expertise in the complex work of product creation, while operational value streams excel at efficient, ongoing delivery. Each focuses on what it does best.
  2. Elimination of Functional Handoffs: By bringing together all needed specialists within value streams, Prod•gnosis eliminates the costly handoffs between departments that plague traditional development.
  3. Permanent Capability Building: Unlike project teams that form and disband, the PDVS builds institutional knowledge about effective product creation that compounds over time.
  4. Perfect Products and Perfect Delivery Systems: The PDVS designs not just the product itself, but the entire operational system that will deliver it—ensuring that both are optimised together.
  5. Knowledge Reuse Without Reinvention: Learnings from creating one operational value stream inform the next, creating an accelerating cycle of organisational learning.
  6. Optimised Flow of Work and Value: The dual value stream structure dramatically improves flow—the smooth, efficient movement of work through the organisation. By organising around value streams rather than functional departments, Prod•gnosis eliminates the queues, batching, and priority conflicts that impede traditional development. Work moves continuously from concept to cash without the stops, starts, and detours that characterise departmental handoffs. This improved flow translates directly to faster time-to-market, higher quality, and more innovative products. Most importantly, it creates flow not just of individual products but of the organisation’s entire product portfolio—a pipeline of innovation that continuously delivers value to customers and revenue to the business. See also Toyota’s TPDS and their reliance on set-based concurrent engineering.

How This Differs from Traditional Approaches

To appreciate the magnitude of this innovation, consider how traditional organisations develop products—through a complex matrix of functional departments:

  • Marketing defines requirements
  • Product management prioritises features
  • Design creates user experiences
  • Engineering builds technical components
  • Quality assurance validates functionality
  • Operations prepares for deployment
  • Sales and support prepare for customer engagement

Each handoff between departments introduces delays, misunderstandings, and compromises. Each group optimises for their local priorities rather than the whole product. The result? Watered-down products that take too long to develop and fail to delight customers.

The contrast is stark: In traditional organisations, product development happens through departments with competing priorities. In Prod•gnosis, product development happens through a dedicated value stream designed specifically for that purpose, which then creates operational value streams designed specifically for each product.

Proof in Practice

Organisations that have implemented this dual value stream model report transformative outcomes that traditional approaches simply cannot match:

  • Dramatic acceleration of time-to-market as handoffs between functional silos disappear
  • Higher-quality products as specialists collaborate directly rather than throwing work “over the wall”
  • Reduced coordination overhead as value streams contain all needed capabilities
  • Continuous learning as the PDVS applies insights from each new product to the next
  • True cross-functional integration as specialists work together daily rather than in isolated steps (Cf. the Obeya or Big Room)

Most significantly, the PDVS becomes an organisational capability that competitors cannot easily replicate—creating sustainable competitive advantage through structural innovation rather than product features alone.

The Solution

This is where Prod•gnosis enters the conversation—not as yet another change mangement approach but as a fundamentally different organisational model for product development.

Prod•gnosis (from “Product” and “Gnosis,” meaning knowledge) reimagines your entire approach to creating and delivering new products. Rather than treating product development as a series of projects passed between departments, it organises your business around two types of value streams:

  1. Operational Value Streams dedicated to specific product lines
  2. A Product Development Value Stream specialised in creating new operational value streams

This revolutionary structure delivers five key advantages:

1. Liberation from IT Control

In traditional organisations, software development sits within IT departments, creating a fundamental misalignment of priorities. Prod•gnosis moves software development into the Product Development Value Stream, ensuring technical priorities align directly with market opportunities.

2. Whole Product Integration

Rather than developing technical components in isolation, Prod•gnosis integrates all aspects of the product experience—functionality, user experience, marketing, support—into a cohesive development process inspired by Toyota’s “Big Room” (Obeya) concept.

3. Specialist Collaboration Without Silos

Specialists maintain their expertise without being trapped in functional departments. They collaborate directly with other disciplines in dedicated value streams, eliminating the costly handoffs and misalignments that plague traditional structures.

4. Service-Oriented Perspective

Even physical products are ultimately services delivering value to customers. This perspective shift generates innovative approaches to both product design and ongoing customer relationships.

5. Organisational Capability Building

Instead of assembling and disassembling project teams, Prod•gnosis builds persistent organisational capabilities for product development, creating sustainable competitive advantage through institutional learning.

Proven Results

Organisations that have embraced Prod•gnosis principles report transformative outcomes:

  • Time-to-market reductions of 40-60% by e.g. eliminating cross-functional handoffs
  • Development cost reductions of 25-35% through elimination of coordination waste
  • Breakthrough innovations enabled by cross-functional collaboration
  • “Mafia Products” so compelling that customers can’t refuse them and competitors can’t match them (See: Goldratt and the Theory of Constraints)

Most importantly, they’ve built sustainable capability for continued market leadership—not through one-off successes but through systematic organisational design focused on flow, value, and knowledge.

Your Next Step

Transforming your product development approach doesn’t happen overnight, but it begins with recognition that the collective assumptons and beliefs baked into your current structure may be the very thing preventing you from achieving your market ambitions.

The Prod•gnosis Handbook (coming soon) will provide a comprehensive guide to implementing this revolutionary approach in your organisation. It offers both the conceptual framework and practical implementation steps needed to transform how your organisation develops products.

The world’s most innovative companies (Toyota, Haier, etc.) have already moved in this direction. Will you join them, or will you be explaining to your board in three years why your competitors consistently beat you to market with superior offerings?

The choice—and the competitive consequences—are yours.


Ready to explore how Prod•gnosis could transform your organisation’s approach to product development? The Prod•gnosis Handbook will provide a comprehensive guide to implementing this revolutionary approach. In the mean time, you might like to get in touch with the FlowChainSensei (Bob Marshall). Getting started on this adventure is a simple as adding a comment to this post.


You may also like to listen to an (AI-generated) Deep Dive conversation on this post.

The Why of FlowChain: Deliberate Continuous Improvement

In my career, working with hundreds of companies, I’ve almost never seen organisations* take a truly deliberate approach to continuous improvement. It’s nearly always treated as an afterthought or add-on to business-as-usual (BAU). But real transformation requires making continuous improvement an integral and core part of daily work. This is the “why” behind FlowChain – enabling deliberate, in-band continuous improvement.

In other words, applying the same disciplines from product development, delivery, etc. to the business (sic) of delivering continuous improvements  – continuously improving the way the work works.

What Is FlowChain?

So what is FlowChain? At its core, it is a system for managing flow – both the flow of outputs and the flow of improvements to the way the work works, concurrently and by the same means. And by “flow”, I mean the steady progress of work from request to completion through all steps in a process. Flow is optimised when the right work is happening at the right time by the right people. Roadblocks, delays, and waste are minimised or eliminated.

Flow

Optimising flow delivers the following benefits:

  • Increased productivity – less time wasted, more work completed
  • Improved quality – fewer defects, rework minimised
  • Better customer service – faster response times, reliability
  • Higher employee engagement – less frustration, more joy

But achieving flow requires continuous improvement. Problems must be made visible. Waste must be reduced iteratively. Roadblocks must be cleared continuously.

This is why FlowChain incorporates improvement into its regular rhythm. Each cycle follows a deliberate sequence:

  • Plan – Select and sequence the upcoming work.
  • Execute – Complete the work while tackling issues.
  • Review – Analyse completed work and identify improvements.
  • Adjust – Make changes to improve flow.

Unlike most continuous improvement efforts – that are separate from BAU – FlowChain makes improvement an integral in-band activity. The rapid cycles provide frequent opportunities to reflect, gain insights, and act.

Compounding Benefits

Over time, the compounding benefits are immense. Teams develop a “flow habit”, where improving flow becomes second nature. Powerful capabilities like root cause analysis, A3 problem-solving, improvement katas, and change management are honed.

In my experience, this deliberate approach is transformative. Teams gain tremendous agency to systematically improve their own flow. The organisation as a whole cultivates a culture of continuous improvement. And customers experience ever-better service and responsiveness.

The “why” of FlowChain is simple – create focus, visibility, accountability, and agency to drive continuous improvement. The results – ever better flow, reduced waste, and sustainable transformation. Deliberate, in-band continuous improvement stops being an aspiration and becomes a reality.

*Ask me about the exception.

Why Value Streams?

Just Another Way of Dividing A Whole Into Parts?

Are value streams just one more way of dividing a whole organisation into parts? Isn’t “division into parts” a hallmark and defining characteristic of the Analytic mindset? And something we’re trying to avoid in pursuit of the Synergistic ideals presented in Quintessence? 

As the inimitable Russell L. Ackoff says:

A system is more than the sum of its parts; it is an indivisible whole. It loses its essential properties when it is taken apart. The elements of a system may themselves be systems, and every system may be part of a larger system.

~ Russell L. Ackoff

The Structure Of The Moment

At The Quintessential Group, we’ve chosen value streams as the structure of the moment. Not as a mean to subdivide the Group into parts, but as an experiment, as a way to encourage synergies within the whole. Our hypothesis is that by divorcing hierarchy from structure, we create an environment better suited to serving the needs of the Folks That Matter™.

We are concerned with total systems performance, and the relationships between the parts (value streams) much more than managing each part, each value stream, separately. In fact, the “management” of each part is pretty much irrelevant and not something we’ll be spending time on.

Even The Quintessential Group as a whole is part of larger, or containing, systems. We may choose to see the Group, and its value streams, as holons, as holarchies. As stable intermediate forms. See: The Parable of the Two Watchmakers.

Borrowing from the language of Arthur Koestler, a value stream serves as a subsystem within the larger system: We can regard it as an evolving, self-organizing structure while simultaneously a part of a greater system composed of other value streams i.e The Quintessential Group.

Enough With The Philosophy Already

So, what practical benefits do we foresee from the value stream approach?

  • More coherent (less fragmented) experience for clients.
  • Improved flow of value.
  • Increased synergies resulting in a more effective organisation and thus affording an improved customer experience.
  • Reduction in delays, wastes, and non-value-adding activities.
  • Improvements in takt time and smoothness of value flow.

How do you feel about value streams as e.g. a structuring approach for organisations?

– Bob

 

Implementing Prod•gnosis

One pleasing aspect of our new startup – The Quintessential Group, is the opportunity to implement Prod•gnosis.

We’re intent on building an organisation (the Group) along value stream lines. With a separate value stream for each market we serve. In mooted order of instantiation:

    • Quintessential Teams (rent a gelled team by e.g. the fortnight)
    • Quintessential Recruiting (we source Quintessential people)
    • Quintessential Worx / Works (commission us to build the solutions you need)
    • Quintessential Culture Shift (Digital Transformations, Culture Change, etc.)
    • Quintessential Memes (meme exploration and installation services)
    • Quintessential People (serving clients’ HR function)
    • Quintessential Academy (training in all things Organisational Psychotherapy and Quintessential)
    • Quintessential Coaches (organisational coaches for rent)
    • Quintessential Mentors (personal mentors for rent)
    • Quintessential Tutors (personal tutors for rent)

PDVS

So, naturally – naturally for a value-stream based organisation anyways – we’re building the “product development value stream” first, albeit incrementally and in parallel with the first operational value stream i.e. Quintessential Teams. Eating our own dog food, you might say.

We’ll keep you posted on progress.

You can :

– Bob

Further Reading

Marshall, R. (2014). Product Development 101. [online] Think Different. Available at: https://flowchainsensei.wordpress.com/2014/10/15/product-development-101/ [Accessed 1 May 2022].