Kaizen Teams

Dropdown
Dropdown arrow for the table of contents.

Table of Contents

Clock icon for reading time.
Time to read

·

12

Calendar icon for the publish date.
Published on

·

September 21, 2026

Refresh icon for the last updated date.
Last updated on

·

September 21, 2026

Martin Mato, Principal Software Engineer at Kaizen Softworks

Martin Mato

LinkedIn icon.

Sci-Fi addict

Principal Software Engineer

AI

AI

Project Management

Project Management

When PMs can ship code, what changes for Engineering?

Calendar icon for the publish date.
Published on

·

September 22, 2026

Refresh icon for the last updated date.
Last updated on

·

September 21, 2026

Clock icon for reading time.
Time to read

·

12

Martin Mato, Principal Software Engineer at Kaizen Softworks

Martin Mato

LinkedIn icon.

Principal Software Engineer

AI has changed what Product Managers can do.

A PM can now go from an idea to working software in hours. They can build a flow, put it in front of a customer, learn from it, change it, and test again without waiting for every iteration to go through Engineering.

That creates an opportunity for product teams. It also creates a new challenge.

Just because a PM can build something doesn’t mean that thing is ready to become production software.

If we don’t rethink how Product and Engineering work together, faster prototyping can become more code for Engineering to untangle, more unclear ownership, and more pressure to turn experiments into production features.

The answer is to separate exploration from construction.

PMs and engineers are solving different problems

During product discovery, the PM is trying to answer: Should we build this?

That means testing assumptions, changing direction quickly, throwing things away, and getting something real enough in front of a customer to learn from it.

Engineering is solving a different problem: How do we build this correctly?

That means thinking about architecture, security, maintainability, performance, edge cases, and everything else required for software that has to live in production.

Both need AI. But they don’t need the same working conditions.

Exploration benefits from speed, autonomy, and low friction. Construction needs stronger guarantees and guardrails. Trying to optimize the same environment for both creates tension.

So instead of asking how PMs can safely contribute code to the production codebase, there’s a more useful question: What if PMs had their own space to build and validate ideas?

Give PMs a safe place to explore

A PM working with an AI coding agent can build functional versions of new ideas. Not a Figma screen. Not a ticket describing what something might do.

Working software that can be used to test the product experience. The important part is that this environment is separate from production.

That boundary gives the PM freedom to experiment without requiring the same controls we’d expect from production software. The environment can be designed so experiments can’t affect the live product or access things they shouldn’t.

Now the PM’s workflow can look more like:

Idea → build → test with users → learn → iterate

Engineering doesn’t need to be pulled into every cycle.  Engineering still matters. It  gets brought in once Product has stronger evidence about what’s worth building.

The prototype shouldn’t be the handoff

This is where things can go wrong.

If a PM spends two days building something with AI and then gives the repository to Engineering saying, “It mostly works, can you finish it?”, we haven’t improved the product development process. We may have just moved the mess downstream.

The prototype should help answer product questions. It shouldn’t make technical decisions on Engineering’s behalf.

What Engineering needs from exploration is intent.

  • What does the feature need to do?
  • How should it behave?
  • What did we learn from customers?
  • What happens in the important edge cases?
  • How will we know when the production version works as intended?

That becomes the handoff.

At Kaizen, we’ve been exploring a model where the bridge between the two cycles is a behavioral specification and a test plan, supported by the working prototype as a reference. The implementation itself stays behind.

What crosses into construction is the spec: a behavioral description, a test plan, and a link to the prototype as reference. The prototype itself stays where it was built.

In simple terms:

Product owns the what. Engineering owns the how.

That distinction matters even more now that AI makes it so easy for both sides to generate code.

What the workflow could look like

A PM starts with a product hypothesis. Instead of immediately turning it into a backlog item, they use AI to build enough of the experience to test it. They put it in front of users. They discover that part of the original idea was wrong. So they change it. They test again.

Once the problem and desired behavior are clear enough, the PM closes the exploration cycle with a clear specification and acceptance criteria.

Engineering then starts from that understanding, not from the PM’s experimental code only. They decide how the feature fits into the architecture, how it should be implemented, what needs to be verified, and how it reaches production.

The result is two parallel forms of autonomy:

  • PMs don’t need Engineering for every experiment.
  • Engineers don’t inherit implementation decisions from every experiment.

More autonomy doesn’t have to mean less ownership.

AI can make discovery faster

A lot of the conversation around AI in software teams is still about developer productivity. How much faster can we write code? How much implementation can an agent take on?

Those questions matter. But for Product, there may be an even bigger opportunity upstream. AI can shorten the distance between having an idea and learning whether that idea is any good.

That changes what PMs can bring to an engineering team. Instead of: “We think customers want this.” They can increasingly say: “We tested this behavior with customers. Here’s what worked, what didn’t, and exactly what we now need the product to do.”

That’s a much better starting point for building production software.

If you have a prototype and want to take the idea into production, we can help you determine what needs to happen next.

AI has changed what Product Managers can do.

A PM can now go from an idea to working software in hours. They can build a flow, put it in front of a customer, learn from it, change it, and test again without waiting for every iteration to go through Engineering.

That creates an opportunity for product teams. It also creates a new challenge.

Just because a PM can build something doesn’t mean that thing is ready to become production software.

If we don’t rethink how Product and Engineering work together, faster prototyping can become more code for Engineering to untangle, more unclear ownership, and more pressure to turn experiments into production features.

The answer is to separate exploration from construction.

PMs and engineers are solving different problems

During product discovery, the PM is trying to answer: Should we build this?

That means testing assumptions, changing direction quickly, throwing things away, and getting something real enough in front of a customer to learn from it.

Engineering is solving a different problem: How do we build this correctly?

That means thinking about architecture, security, maintainability, performance, edge cases, and everything else required for software that has to live in production.

Both need AI. But they don’t need the same working conditions.

Exploration benefits from speed, autonomy, and low friction. Construction needs stronger guarantees and guardrails. Trying to optimize the same environment for both creates tension.

So instead of asking how PMs can safely contribute code to the production codebase, there’s a more useful question: What if PMs had their own space to build and validate ideas?

Give PMs a safe place to explore

A PM working with an AI coding agent can build functional versions of new ideas. Not a Figma screen. Not a ticket describing what something might do.

Working software that can be used to test the product experience. The important part is that this environment is separate from production.

That boundary gives the PM freedom to experiment without requiring the same controls we’d expect from production software. The environment can be designed so experiments can’t affect the live product or access things they shouldn’t.

Now the PM’s workflow can look more like:

Idea → build → test with users → learn → iterate

Engineering doesn’t need to be pulled into every cycle.  Engineering still matters. It  gets brought in once Product has stronger evidence about what’s worth building.

The prototype shouldn’t be the handoff

This is where things can go wrong.

If a PM spends two days building something with AI and then gives the repository to Engineering saying, “It mostly works, can you finish it?”, we haven’t improved the product development process. We may have just moved the mess downstream.

The prototype should help answer product questions. It shouldn’t make technical decisions on Engineering’s behalf.

What Engineering needs from exploration is intent.

  • What does the feature need to do?
  • How should it behave?
  • What did we learn from customers?
  • What happens in the important edge cases?
  • How will we know when the production version works as intended?

That becomes the handoff.

At Kaizen, we’ve been exploring a model where the bridge between the two cycles is a behavioral specification and a test plan, supported by the working prototype as a reference. The implementation itself stays behind.

What crosses into construction is the spec: a behavioral description, a test plan, and a link to the prototype as reference. The prototype itself stays where it was built.

In simple terms:

Product owns the what. Engineering owns the how.

That distinction matters even more now that AI makes it so easy for both sides to generate code.

What the workflow could look like

A PM starts with a product hypothesis. Instead of immediately turning it into a backlog item, they use AI to build enough of the experience to test it. They put it in front of users. They discover that part of the original idea was wrong. So they change it. They test again.

Once the problem and desired behavior are clear enough, the PM closes the exploration cycle with a clear specification and acceptance criteria.

Engineering then starts from that understanding, not from the PM’s experimental code only. They decide how the feature fits into the architecture, how it should be implemented, what needs to be verified, and how it reaches production.

The result is two parallel forms of autonomy:

  • PMs don’t need Engineering for every experiment.
  • Engineers don’t inherit implementation decisions from every experiment.

More autonomy doesn’t have to mean less ownership.

AI can make discovery faster

A lot of the conversation around AI in software teams is still about developer productivity. How much faster can we write code? How much implementation can an agent take on?

Those questions matter. But for Product, there may be an even bigger opportunity upstream. AI can shorten the distance between having an idea and learning whether that idea is any good.

That changes what PMs can bring to an engineering team. Instead of: “We think customers want this.” They can increasingly say: “We tested this behavior with customers. Here’s what worked, what didn’t, and exactly what we now need the product to do.”

That’s a much better starting point for building production software.

If you have a prototype and want to take the idea into production, we can help you determine what needs to happen next.

Common questions

Does Engineering inherit the prototype's technical debt?

No, and that's the point of the separation. Engineering starts from the behavioral specification and acceptance criteria, not from the exploration repository. The prototype stays as a reference for how the experience should feel, not as a starting codebase.

What happens when the prototype already works and the business wants to ship it?

This is the most common pressure, and it has to be settled before it shows up rather than in the moment. Agree upfront that the prototype is not a release candidate and that the deliverable of exploration is the specification. Without that agreement, the model breaks the first time something is urgent.

Doesn't writing a behavioral spec just add work for the PM?

Most of the drafting can be automated. The coding agent already has the exploration session (what was built, what changed after user feedback, and which flows ended up working), so it can produce the first version of the behavioral spec and acceptance criteria. What stays with the PM is the judgment: confirming what the tests proved, correcting what the agent inferred, and deciding which behaviors are non-negotiable. Reviewing a draft is a much smaller task than writing a document from scratch.

1
What is the difference between working with Kaizen versus a single designer?

Related Articles

View all articles

·

Nov 4, 2026

SmartSense Live 2026 | Food Safety Summit

SmartSense LIVE26 recap: SmartSense ONE’s launch, the Disruptive Technologies acquisition, AI assistant KAI, and what it means for food safety and compliance teams.

Clock icon for reading time.

12 read time

Read more

SmartSense LIVE26 recap & takeaways

SmartSense LIVE26 took place October 7-9, 2026, at the Hyatt Regency Austin in Austin, Texas. The conference focused on food safety, compliance, and the role of connected technology in daily operations.

It was our first time attending LIVE, in the first year the conference opened to the wider industry. For us, it was also an opportunity to sponsor and support SmartSense, a company we’ve worked with since 2019.

Event details
Dates October 7–9, 2026
Venue Hyatt Regency Austin, Austin, Texas
Organizer SmartSense by Digi
Access October 7–9 for SmartSense customers; October 8–9 for industry attendees
Price $215.42 for industry attendees

Who SmartSense LIVE26 is for

SmartSense LIVE is designed for people responsible for safety, compliance, and operational performance. Its audience spans food service, healthcare, logistics, and other industries where monitoring physical conditions is part of everyday work.

That makes it relevant to operations and food safety leaders, as well as the technology teams supporting them. A monitoring system has to fit how people check conditions, respond to issues, and document what happened.

SmartSense LIVE26’s attendees spanned retail, healthcare, food service, and education, including Costco, CVS Health, and honeygrow. Speakers brought perspectives from operations, food safety, compliance, IT, and procurement.

What SmartSense LIVE26 was like

The main focus of the event were the SmartSense ONE presentation and the acquisition of Disruptive Technologies, which gave us a clearer picture of the company’s direction: connecting what happens in physical environments with the decisions and tasks that follow.

SmartSense ONE

SmartSense ONE brings SmartSense and Jolt capabilities into a modular platform with shared data and a common web and mobile experience, including offline support. Its seven modules cover monitoring, daily tasks, food safety, audits, maintenance, labeling, and staff scheduling. Customers can choose the capabilities they need and combine them as their requirements grow.

The focus extends from collecting data to acting on it

SmartSense describes its approach in three stages: Sense, Understand, and Act. Sensors capture conditions in the physical world, analytics and AI interpret the data, and digital workflows help teams respond.

The DT acquisition will strengthen sensing and expand SmartSense’s reach

On October 1, Digi announced an agreement to acquire Disruptive Technologies for $130 million. DT brings proprietary sensor technology, more than 250,000 deployed sensors, and devices designed to operate for up to 15 years. The acquisition would bring that technology into SmartSense, establish a stronger commercial presence in Europe, and expand opportunities in building automation and space occupancy.

Seven years of working with SmartSense

Our relationship with SmartSense began in 2019. Since then, we’ve worked together on product development and modernization as the company has grown and brought acquired products into its ecosystem.

One part of that work involved modernizing a remote monitoring app while incorporating features from other legacy products. The decisions went beyond rebuilding screens: we had to understand which workflows to keep, improve, combine, or retire. The resulting application serves more than 10,000 supply chain teams.

We’ve also worked on the process behind sensor deployments. A mobile installation app brought scanning, assignment, validation, and data synchronization into a guided workflow, helping technicians complete more deployments without adding headcount.

That work gave us a specific reason to be at LIVE: to hear from the people whose routines these systems support, and understand where software could make their work easier.

At our booth, we shared a demo showing how connected systems can work together in practice, along with our AI Adoption Handbook and some swag.

After Austin

Thank you to the SmartSense team for having us as sponsors and for the work we’ve shared across products and teams since 2019. Being part of LIVE added a new setting to that relationship: spending time with the people and organizations those products support.

And thank you to everyone who stopped by our booth, tried the demo, or took the time to tell us about their work.

If there’s a workflow you’d like to explore further, get in touch with us. We can help you clarify the problem and decide what would be useful to test first.

‍

·

Oct 23, 2026

How to build high-fidelity prototypes with AI

How a design system lets Marketing and Product teams use AI to build on-brand prototypes, based on Kaizen’s own experience and turnaround numbers.

Clock icon for reading time.

12 read time

Read more

AI makes it easier for more people across a company to create a first visual version without relying on Design for every step.

Marketing can generate campaign assets. Product managers can turn ideas into prototypes. Teams can make an idea visible earlier in the process.

That creates a new design problem.

If more people can create, how do you make sure the output still reflects the decisions Design has already made about hierarchy, typography, spacing, composition, and brand?

A design system can help.

When its rules, components, templates, and examples are available to AI tools, other teams can create within boundaries Design has already defined.

Design does not have to build every first version. It can focus on reviewing important decisions and improving the system when recurring problems appear.

A design system can carry judgment beyond the Design team

A design system gives teams shared rules for creating consistent work.

It can define:

  • Color, typography, spacing, and composition.
  • Components and how they behave.
  • Templates for recurring layouts.
  • Examples that show how those decisions work together.

That context is useful for AI too.

Without it, someone creating a page, presentation, or social post has to explain what “on brand” or “well designed” means in a prompt.

With a design system, many of those decisions are already documented. AI has a reference for how content should be structured, which components belong together, and what kinds of compositions fit the brand.

Teams get a starting point that is closer to the company’s existing visual language without having to describe it from scratch.

What this can look like across teams

Marketing can create recurring assets with less production dependency

Marketing often works with recurring formats such as social posts, campaign pages, and event assets.

Templates can give the team enough structure to create a usable first version independently. A social template, for example, can define typography, spacing, image treatment, and composition while leaving room for the content to change.

Design can then focus its review on the decisions that need attention.

Product teams can make ideas visible earlier

Product managers often need something visual before they need production-ready design.

If an AI tool has access to the same components and rules the product already uses, a PM can create a rough prototype that is closer to the real product than a generic wireframe.

The prototype is not a design direction by itself. It gives Product and Design something concrete to discuss.

Instead of spending time explaining what an idea might look like, they can focus on whether the flow makes sense, what needs to change, and where deeper design work is needed.

Generated work can show where the system is weak

AI does not only use the design system. Its output can also reveal where the system needs more guidance.

We saw this while using our own design system with AI at Kaizen.

Our Design team created the system while redesigning the Kaizen website. It documented the site’s colors, typography, composition rules, components, and templates. Marketing later began using that same system with AI to create website prototypes and social content.

One pattern kept appearing.

The AI put almost everything inside boxes.

Text, images, and entire sections appeared inside containers, even when a more open composition would have worked better.

Design reviewed the source material and found that many of the examples and rules leaned toward contained compositions. The AI was reproducing the patterns it had been given.

The team added guidance and examples for other layout approaches. The generated work became more varied and used more open compositions.

Instead of correcting the same problem in each new asset, the team improved the guidance that influenced future outputs.

That is one of the useful side effects of this process: recurring corrections can point to gaps in the system itself.

Autonomy still needs boundaries

Giving more people the ability to create does not mean every deliverable should follow the same workflow.

A recurring social post built from an established template may only need a quick review. A new product workflow may need much more involvement from Product and Design before anyone treats the prototype as a direction.

Teams can start by agreeing on three things:

What can teams create independently?

Identify recurring formats where the main design decisions are already understood.

What needs Design review?

Decide which outputs need a light check and which need deeper involvement.

What should go back into the system?

When the same correction happens repeatedly, update the shared rule, component, template, or example.

These boundaries make it clear where teams can move independently and where Design’s judgment is still needed.

What this changed for us at Kaizen

Before introducing this process, a LinkedIn visual could take more than two weeks from request to delivery once other priorities, coordination, review, and revisions were included.

We now estimate that a similar piece can move from copy to something ready to publish in about one afternoon.

For website work, a process that previously took around two weeks can now start with a Marketing-generated prototype in about two days, followed by roughly two days of Design refinement and production.

These are elapsed turnaround estimates, not active design hours. Reusable templates, the design system, clearer responsibilities, and the review process all contribute to the difference.

The biggest change is where the work starts.

Marketing can reach a concrete first version sooner. Design can spend more time refining important decisions and improving the system that will influence the next piece too.

For teams exploring this approach, start with one repeatable format.

Define the rules, examples, and templates needed to create a reasonable first version. Agree on where Design should enter the process. Then pay attention to recurring corrections.

If the same typography, layout, or composition problem keeps appearing, improve the shared guidance instead of fixing the same issue every time.

The goal is to make Design’s decisions reusable while keeping Design involved where its judgment matters most.

If you are working through the same questions, we can help you turn your existing design decisions into practical rules, templates, and review workflows your teams can use with AI.

‍

llms.txt