Product Development Cycle: The Dynamic Link (6/8)

Integrating the Component E into the Architecture of Excellence

In our ongoing exploration of the Architecture for Product Excellence, we've previously delved into the foundational principles that guide product development (Component A), the structural backbone that sustains it (Component B), the system for designing the future product experience (Component C), and the method for delivering that vision (Component D). Now, we turn our attention to Component E: The Product Development Cycle, the engine that drives the product from concept to market and beyond.

This component is not merely about following a linear path; rather, it’s about creating a dynamic and iterative process that incorporates feedback loops, adapts to changing market conditions, and continuously delivers value to users. Component E is where the strategic vision defined in the Experience Architecture (Component C) meets the operational realities of Experience Delivery (Component D). It provides the framework to translate those strategic elements into a tangible product life cycle.

In this article, I will explore the key phases of the product development cycle and how they interact to create a seamless and efficient journey. I will also examine how the previous components of the Architecture of Product Excellence inform and shape each phase. This is not just a step-by-step guide, but a deep dive into the core mechanics of continuous value delivery.

By understanding and mastering Component E, you'll have the tools necessary to transform your vision into a living, breathing product.

For what it's worth, in the real world product development is a complex process with a high risk of failure, primarily due to building the wrong product. However, innovative companies employ strategies to mitigate these risks and deliver products that resonate with users. I really admire how Spotify has publicized their product development process. It’s been a while since I adopted their model as a guide and inspiration, while also adapting the language and implementation to better suit my needs.

The Product Development Cycle: Shape, Build, Ship, Optimize

SHAPE

This initial stage focuses on defining the product and its purpose. A small, cross-functional team develops a product definition, which is a concise document outlining the product's story, key metrics, and what would be the frequently asked questions.. A compelling narrative is crafted, which is a story that the product will tell to the world, often presented in the form of a press release. Prototypes are created to test the look and feel of the core experience. The goal of this stage is to mitigate product risk cheaply and safely.

The SHAPE stage ends when management and the team agree that the product is worth building.

BUILD

The SHAPE team expands into a more permanent squad, with the necessary skills to develop the product. The goal here is to build a Minimum Viable Product (MVP) that is good enough to be released to users and is good enough to test the product. The MVP should be "narrative-complete," meaning it fulfills the basic product narrative, but not necessarily feature-complete. This stage focuses on building production-level code and quality into the product.

This stage is complete when the team and management agree that the product meets the basic narrative and is ready to be released to users.

SHIP

In this stage, the product is gradually rolled out to all users, beginning with a small percentage. The initial rollout allows for data collection and validation of the product's hypotheses. The rollout is gradually increased as the product proves itself, while operational aspects of the product are managed.

This stage is complete when the product is available to all users, but the product will continue to evolve.

OPTIMIZE

The product is now available to all users, and the squad focuses on continuous improvement through experimentation, testing, and metric analysis. The product stays in this stage unless it is shut down or re-imagined. The team may reach a point of diminishing returns on the product and decide whether to focus on other products or re-imagine the current product.

The four-stage model of product development is designed to manage risk gradually and release products quickly. The biggest risk in product development is building the wrong product, meaning a product that doesn't delight users or improve key metrics. Each stage is designed to mitigate this risk in an efficient way.

The SHAPE phase reduces risk in a cost-effective way, while the BUILD phase is more costly but essential to create an MVP that can be tested with real users. The SHIP and OPTIMIZE phases help to ensure that the product fulfills its promise and remains relevant over time. This process enables teams to deliver products that users love, mitigating the risk of building the wrong thing.

This model also helps teams transition from a product with a great initial launch to a product that becomes amazing due to continuous tweaks. This approach ensures that products are continuously improved based on user data and feedback, rather than being "complete" and static at the time of launch.

I'll conclude this section with the final thoughts from Spotify's document, where they outline their model:

“If some parts of this model made you think “duh, I already knew that, we’ve been doing that for decades”, you’re probably right. This model isn’t about New And Amazing, it is just about Stuff That Works - new or old doesn’t really matter. I find this combination of practices to be very inspiring and powerful, and I hope you find something that could be useful in your context.”

However, a newcomer could potentially introduce fresh viewpoints to the product development process.

The Transformative Impact of AI on Product Development

AI has the potential to radically transform the product development and growth process. AI is shifting constraints and possibilities regarding which products and features are built, how they are developed, how they grow, and how team roles and organizational structures evolve. This shift is so significant that some believe AI’s impact is being underestimated.

As the folks at Reforge are stating, here are some of the ways that AI is reshaping product teams:

• Expanded Exploration: AI enables teams to explore many paths instead of just one or two, resulting in more innovative and validated solutions. AI allows for simultaneous testing of multiple interfaces, copy variations, and technical approaches.

• Rapid Prototyping: The traditional reliance on documentation is giving way to prototype-first development. AI is enabling the creation of functional prototypes in hours instead of weeks.

• Problem Solving: AI expands the realm of what problems are solvable and leads to a shift from solving computation problems to solving learning problems.

• Prioritization: AI introduces new factors into product prioritization such as the feasibility of more complex solutions, the impact of personalization at scale, new risks such as bias, and cost impacts based on model use.

• Solution Reinvention: AI allows for adaptive, personalized solutions, moving from "enabling work" to "doing the work" for the customer.

• Redefined Roles: AI is blurring the lines between roles such as product managers, engineers and marketers, and will impact how product teams are organized.

• Growth Model Evolution: AI is poised to disrupt traditional growth models, requiring products to be discoverable and evaluable by AI systems. This may lead to new distribution channels where AI agents become the primary audience for product promotion.

• Rethinking Product Stacks: AI systems struggle with fragmented tools and compound errors, so an integrated AI-native product stack is necessary.

The challenge right now is that there is a large gap between AI promise and reality of implementing all this change in product teams.

As you may know, emerging technologies often follow a predictable pattern. Initially, the focus is on pure functionality - making the technology work. Only after this basic capability is established does the focus shift to user experience. The true value of the technology is unlocked when designers and developers refine it to be both enjoyable and essential.

That’s where we are with AI today. The focus is on bigger models, better accuracy, faster responses—all necessary steps, but not particularly exciting for product folks who are more interested in crafting experiences rather than tweaking machine learning parameters.

The integration of AI into daily life and creative workflows will mark a significant shift in the AI landscape. As AI transitions from being a costly experiment to a readily available tool, the focus will move beyond mere generation and variation of content, towards a more nuanced approach that emphasizes usability, user experience, and genuine creative enhancement.

In this new era of AI, the technology will not just be a generator of endless options, but a thought partner, collaborator and creative assistant that augments human thinking, refining and redefining creative processes. AI will enable product people to explore uncharted territories of creativity and innovation.

Rather than simply churning out rapid prototypes and mockups, AI will facilitate deeper, more conceptual creative endeavors. It will push the boundaries of what's possible in product design and development. This shift will unlock new realms of creative expression, leading to more innovative, user-centric, and impactful products.

With no doubt AI is a transformative force that accelerates the development cycle, from ideation to commercialization, enabling teams to innovate faster, test more rigorously, and adapt continuously. However, as we integrate AI into every phase, it is imperative to remain vigilant about the design’s alignment with user mental models. Avoiding the trap of merely replicating internal software logic, and instead focusing on creating intuitive, human-centered experiences, is key to achieving product excellence.

Mental Models: Bridging the Gap Between Implementation and User Experience

The concept of a mental model is crucial in product design and development. A mental model is an internal understanding of how a product or system should work based on previous experience, knowledge, and expectations. There are three key mental models to consider:

• Implementation Model: This reflects the internal logic of the system from a technical perspective.

• User's Mental Model: This is the user's understanding of how a product should work.

• Represented Model: This is how the interface represents its functionality to the user.

The goal of successful design is to align the represented model with the user's mental model. The thing is that early stage founders often fall into the trap of designing an interface that mirrors the implementation model, which results in a less intuitive and a poor user experience. It´s not uncommon that Founders focus on the implementation model because their own mental model already has an understanding of the backend and product logic, resulting in a product that makes sense to them, but not necessarily to the user.

The key is to design for the user's mental space and understand that different tasks may be perceived differently. This is important in both the overall product architecture and the design of individual interface elements.

Here the Component C (Experience Architecture) plays its part. A well-defined experience architecture and strategy informs the SHAPE and following phases, ensuring that the product narrative and design remain cohesive, user-centric, and deliver the expected outcomes.

The BUILD and SHIP phases rely on the delivery methods established in Component D, ensuring smooth rollouts, continuous feedback integration, and relentless resources optimization.

And don’t forget that the structural foundation built in Component A (Core Philosophy) and Component B (Backbone) should also enable and drive decision-making throughout all stages of the product development cycle nurturing a strong culture of product excellence.

By systematically integrating all these components, product teams can bridge the gap between vision and execution—creating products that are not only functional and scalable but also deeply impactful and beloved by users.

Practical Strategies to Form a High-Performing Cycle

After spending years helping teams implement product development cycles, I've learned that the difference between theory and practice can be vast. Let me share some practical strategies that I've seen work in the real world.

1. Building a Strong SHAPE Muscle

The Shape phase is where most teams struggle, often rushing through it. Here's how to strengthen this critical phase:

• Create a 'Shape Team' Structure

  • Keep it small (3-5 people)

  • Mix product, tech, and design perspectives

  • Include someone who can represent the business vision

  • Rotate members to spread knowledge

• Implement 'No-Build Friday' One practice that transformed how we shape products is dedicating one day a month (or every two weeks) solely to shaping work. No building, no shipping - just thinking, exploring, and defining. It feels counterintuitive at first, but it saves enormous time and resources in the long run.

• Use the "Press Release First" Technique Start by writing the future press release for your product. I've found this forces teams to:

  • Think from the user's perspective

  • Focus on outcomes, not features

  • Identify the core value proposition early

  • Build alignment around what success looks like

2. Making BUILD More Effective

The build phase often becomes chaotic without the right structure. Here's what works:

• Implement 'Narrative Checkpoints' Every two weeks, stop and ask:

  • Are we still building toward our narrative?

  • What have we learned that might change our direction?

  • Are our technical decisions supporting or fighting our story?

• Use the "Walking Skeleton" Approach Instead of building features in isolation:

  • Create the minimal end-to-end flow first

  • Validate core technical assumptions early

  • Add features around this Skeleton

  • Keep the product always in a working state

• Set Up 'Build Boundaries'

  • Define clear scope boundaries upfront

  • List what you won't build (as important as what you will)

  • Create a 'feature parking lot' for good ideas that don't fit now

3. Making SHIP More Strategic

Shipping isn't just about deployment - it's about orchestrating a successful launch:

• Create a 'Ship Ready Checklist' Some things to consider:

  • Core user journeys tested

  • Key metrics instrumented

  • Support documentation ready

  • Rollback plan in place

  • Customer support team trained

  • Launch communication prepared

• Use the "Lighthouse Customer" Strategy

  • Identify 3-5 key customers who represent your target audience

  • Ship to them first

  • Gather deep feedback before wider release

  • Use their stories in your launch narrative

4. Optimizing the OPTIMIZE Phase

This is where good products become great:

• Implement 'Learning Loops'

  • Daily: Check key metrics

  • Weekly: Review user feedback

  • Monthly: Deep dive into patterns

  • Quarterly: Strategic assessment

• Use the "Optimization Hierarchy" Prioritize improvements splitting them into two sections: Guardrails and Goals. Then balance your backlog following this order:

  • Guardrails

    • Security

    • Infrastructure

    • Reliability

    • Performance

    • Usability

  • Goals

    • Value

    • Growth

Remember, these aren't rigid rules - they're patterns that have worked for me and others to establish and keep a sustainable cycle that helps your team consistently deliver value while maintaining energy and focus.

Product Reviews: The Heartbeat of Product Development

One question I get asked a lot is about Product Reviews. When should they happen? What should they look like? After years of experimenting with different formats and timings, I've found that Product Reviews are not just another meeting - they're the heartbeat that keeps your product development cycle healthy and aligned.

The Three Critical Moments for Product Reviews

In my experience, Product Reviews should happen at three key moments in the cycle:

1. At the End of SHAPE
   This is perhaps the most crucial review. I've seen too many teams jump into building without proper validation of their product direction. During this review, we're not looking at pixels or code - we're evaluating the narrative, the prototypes, and most importantly, the evidence that supports our product decisions. The key question here is: "Are we confident enough to invest in building this?"

2. During BUILD (Milestone Reviews)
   These reviews are different - they're about ensuring we're still on track with our narrative while managing technical and design trade-offs. I usually recommend having these every 2-3 weeks, depending on the project's complexity. The focus here is not on checking task completion but on answering: "Are we still building the right thing, in the right way?"

3. Before Full SHIP
   This final review is your last chance to ensure everything is ready for a full rollout. Beyond the technical aspects, we're looking at the complete user journey, support readiness, and metrics setup. The key question shifts to: "Are we ready to scale this to all users?"

The Format That Actually Works

I've seen Product Reviews fail when they become either too casual or too bureaucratic. Here's the format I've found most effective:

• Pre-Review

  • Squad shares documentation 48 hours before

  • Clear agenda with specific decisions needed

  • Key metrics and data prepared

• During Review (90 minutes max)

  • Context & Progress (15 min)

    • Quick recap of product narrative

    • Progress since last review

    • Key learnings and pivots

  • Deep Dive (45 min)

    • Demo/walkthrough

    • Critical decisions needed

    • Risks and trade-offs

    • Data insights

  • Discussion & Decisions (30 min)

    • Focused on specific questions

    • Clear next steps

    • Explicit go/no-go decisions

• Post-Review

  • Documented decisions

  • Updated action items

  • Shared learnings

Making Reviews Actually Valuable

Here's what I've learned makes the difference between effective and wasteful Product Reviews:

1. Keep the Right People in the Room
   I prefer keeping these reviews small but mighty. Core squad members, key stakeholders, and anyone who needs to make or influence critical decisions. That's it.

2. Focus on Decisions, Not Status Updates
   The worst Product Reviews are the ones that turn into project status meetings. Every review should have specific decisions that need to be made. No decisions needed? Cancel the review.

3. Embrace Constructive Conflict
   Some of the best product insights I've seen came from respectful disagreements during reviews. Create an environment where people feel safe to challenge assumptions and present alternative viewpoints.

4. Link to North Star Metrics
   Every review should connect back to your product's north star metrics. This keeps discussions grounded in impact rather than output.

How Product Reviews Support the Architecture

Product Reviews aren't standalone events - they're integral checkpoints that reinforce our Architecture for Product Excellence:

• They ensure alignment with our Core Philosophy (Component A)

• They validate our product excellence structure's effectiveness (Component B)

• They check our experience architecture's coherence (Component C)

• They confirm our delivery system's efficiency (Component D)

When done right, Product Reviews become powerful tools for maintaining alignment, making better decisions, and ultimately, building impactful products with excellence.

MENTAL NOTE: This is Product Review (PR) as I know today… I believe that AI can transform PRs in a continuous flow infused into the product development cycle. More on this in future posts.

Final Thoughts: Building for Impact, Not Just Output

Product development is a complex and evolving process. By understanding the different stages of product development, the transformative impact of AI, and the importance of mental models, teams can build products that are both innovative and user-friendly.

The Product Development Cycle isn’t just a process—it’s an organizational mindset. When done right, it transforms product teams from feature factories into high-performance engines of impact.

• Shape deeply before committing.

• Build what matters.

• Ship with confidence.

• Optimize relentlessly.

And as AI rewrites the rules of what’s possible, let’s not forget that great products aren’t just about technology. They’re about people and their experience—and the mental models that shape how they experience the world.

---

---

🚨 SPOILER ALERT 🚨

Foto de Pawel Czerwinski na Unsplash

I'm working on a product that fully embodies a CPO-as-a-Software concept…

It's an AI-powered CPO for early-stage founders who have technical/operational expertise but often lack Product savvy. It delivers strategic and tactical guidance, along with a streamlined operating system for taking a product from maybe not that good to damn good, allowing founders to quickly and affordably uncover blind spots in their product function and reach their next major growth milestone.

So if you're a founder without Product expertise and are interested in or even curious about a solution like this, shoot me a message to join the waitlist.

---