The Opportunity for AI in Product Management

AI is helping engineers and designers move faster.

Engineers can write code, explore solutions, and make changes faster. Designers can move from an idea to a prototype faster. Work that once took several rounds can now move forward in a single day.

But faster execution creates another problem.

Someone still needs to understand the request, ask the right questions, define what should be built, and keep everyone working from the same plan.

At Chelsea Labs, that became a bottleneck.

Our engineers and designers were moving faster than a product manager could keep up. As more work moved forward, there were more questions to answer, decisions to document, and tickets to update.

We needed a way for product management to keep pace.

So we built Kendyl, our AI Product Manager.

A client request rarely arrives as a complete plan.

It might come through a Slack message, an email, a screenshot, or feedback on a design.

The client knows what they want to accomplish. But the team needs more detail before it can build the right solution.

Who will use it? What happens when something goes wrong? How does it affect an existing feature? Does it need design work? What should the team test before it goes live?

A product manager turns that request into a clear plan.

Then the work continues.

A designer raises a question. An engineer finds a limitation. The client changes a requirement. A decision made in Slack needs to appear in the tickets and documentation.

Each change may be small. Together, they create a constant stream of work.

As execution gets faster, the work needed to coordinate it grows too.

That was the challenge we faced.

Before Kendyl, much of this work depended on a person moving information between tools.

A request would come in. We would review the conversation, gather the relevant context, and ask clarifying questions.

We were already using AI to help turn that information into product requirements, design requirements, and engineering plans.

But someone still had to carry the process forward.

They had to give the AI the right background, review its output, create the tickets, share the plan, and bring later changes back into the documents.

AI helped with individual steps. Keeping those steps connected still took manual work.

We saw an opportunity to automate that workflow.

An AI model can read a request and draft a plan.

To make that useful inside a business, it needs more.

It needs access to the right information. It needs rules for how the team works. It needs tools to take action. And it needs to know when a person must review a decision.

The system that brings those pieces together is often called an AI harness.

For Kendyl, that means connecting AI to our product process:

• The conversations where requests and decisions happen.
• The documents that explain the project.
• The tickets that organize the work.
• The engineering context that helps the team assess a change.
• The approval steps that keep people in control.

The model provides the reasoning. The harness gives it the context and tools to do useful work.

Kendyl works inside the tools our team already uses, with Slack as the main place for collaboration.

A team member brings a request into a Slack thread.

Kendyl uses the conversation and available project context to understand the problem. It asks questions when important details are missing.

The goal is to make the request clear enough for the team to act on.

Once the request is clear, Kendyl creates a Product Game Plan.

The plan explains the problem, the users, the expected behavior, the business rules, and the conditions the finished work must meet.

It also makes open questions visible.

The team can review and revise the plan in the same thread. That keeps the discussion connected to the document it produced.

After approval and confirmation to create the work, Kendyl creates the relevant Jira tickets.

Our process can include product planning, design planning, design updates, engineering planning, an engineering audit, and QA.

The ticket set follows the work required. A change that does not need design work should not create unnecessary design tasks.

Each ticket carries the information that person needs to move forward.

The conversation does not end when tickets are created.

Designers and engineers can ask questions in the thread. The client can provide more detail. The team can identify a new requirement.

Kendyl helps carry confirmed changes into the relevant plan and tickets. Material changes go back through human approval.

This is where much of the value comes from: keeping the work connected as it evolves.

Kendyl also connects with email, Notion, and GitHub.

These connections help it use information beyond a single Slack thread.

A client email may explain the reason for a request. Notion may contain an earlier decision. GitHub may provide engineering context.

Together, these sources help the team work from a fuller picture of the project.

Consider a client asking:

“Can we let an admin change a scheduled payment amount?”

That sounds like a small feature. But it raises several questions.

Can the admin change any payment, or only future payments? What happens if the payment is already processing? Who has permission? Should the change be recorded? Does the customer need to be notified?

Those answers affect the design, engineering, and testing.

Kendyl can help gather the answers, turn them into a plan, and create the relevant tickets.

If the client later adds a rule, the team can review that change in the same thread and carry it into the affected work.

The request, decisions, and execution stay linked.

We built Kendyl because keeping up had become difficult.

Our engineers and designers could move quickly, but the work around them still required constant attention.

Kendyl automates much of that repeatable product management work: gathering context, drafting plans, creating tickets, and keeping confirmed requirements current.

That gives people more room to focus on the decisions that need their judgment.

Product leaders still decide what matters. Designers still decide how the experience should work. Engineers still assess the implementation. The team still reviews and tests the result.

The aim is to let people spend more time making good decisions and less time moving those decisions between tools.

The value of an AI Product Manager should show up in the way the team works.

We look at questions such as:

• How long does it take to turn a request into approved work?
• How often do engineers or designers get blocked by missing information?
• How much rework comes from unclear requirements?
• Do the tickets reflect the latest approved decisions?
• How much time does the team spend maintaining plans and documentation?

Faster ticket creation alone is not enough.

The work needs to be clear, current, and useful to the people building the product.

Kendyl came from a problem inside our own business.

We understood the workflow because we were doing it every day. We could see where information got lost, where people had to repeat themselves, and where manual coordination slowed the team down.

That gave us a clear place to apply AI.

Other businesses have similar opportunities wherever people spend time collecting information, applying rules, preparing work, and keeping systems updated.

At Chelsea Labs, this is how we approach AI transformation: understand the workflow, identify the bottleneck, and build a system that helps the business move forward.

For our team, that bottleneck was product management.

As AI made design and engineering faster, we built Kendyl to help the rest of the process keep pace.