Over the past 2 years or so, AI tools have enabled product teams to work together in new and sometimes confusing ways. Lines between disciplines like design, product management, and software engineering are blurring at a breakneck pace, and teams can easily find themselves in a spot where it’s unclear how to accommodate this in a way that still prioritizes respect for subject matter expertise, domain ownership, and quality of output. Even within an engineering team, product and design aside, software developers have an easier time contributing to areas they would previously consider outside their comfort zone. This comes with some obvious pros and cons, and more importantly, a need for teams to settle on new principles for product development to meet the moment.

How things used to work

Traditionally, the product development process might look something like this (ignoring feedback/research stages — talking strictly about the steps between knowing we want something and getting it to production):

  1. Product manager works with stakeholders (leadership, customer, etc.) to plan out Feature X. Some back and forth ensues.
  2. If needed, the PM works with a designer on their team to provide a UI/UX spec to tack onto the ticket.
  3. Product manager produces a ticket for an engineer to pick up, with UI spec if relevant.
  4. Teams will work together to estimate and prioritize.
  5. Engineer picks up the ticket and iterates on it.
  6. Feedback is given in the form of testing on a sandbox environment, code review by another engineer, etc.
  7. After the work makes it to production, more feedback and bug reports will come in now that more people have their hands on it.

The pros and cons of AI-generated code and AI tooling

LLMs come with a lot of good and some not-so-good. Among other things, they:

Pros

  • Allow for rapid generation of functional code
  • Can “understand” surrounding context within a code base pretty quickly
  • Can take you from idea to reality quicker than ever
  • Reduce the need for so much process overhead to start sketching out a good idea and get feedback on it
  • MCPs allow us to string together internal tools in powerful ways. See MCP usage example below.

Cons

  • Have a tendency to generate new things / duplicate code without heavy supervision and rigorous review of generated code, which takes time and effort one has to be willing to put in. You can easily find yourself with a +5,000/-120 change set in the blink of an eye.
  • Multiply problems that were already present in our field — new features that conflict with each other because communication boundaries between teams still exists, more things pop up without sufficient documentation or user guides, the size of the code base bloats massively as the company grows.
  • Put the person behind the wheel and reviewers in a place where they’ll often understand the code they “wrote” a lot less than they might have a few years ago.
  • Give people the illusion of ownership over an area they may not actually understand that well without access to their AI tool of choice.

What different groups want

While no team or discipline is a monolith, one can generally assume the following:

  • Everyone wants to solve more problems faster
  • The vast majority of people want to free themselves and their teams from repetitive, mundane work by offloading those tasks to AI agents
  • A good number of people want to try contributing to new areas that felt too outside of their domain before (e.g. an API developer trying to make nice UIs, a sales person wanting to make their own internal dashboard app, or a product manager wanting to include a sandbox deployment alongside the ticket they hand to engineering)
  • Leadership wants to see as much product change and improvement, as fast as possible, without compromising quality (this is historically, and currently, difficult)
  • Subject matter experts across domains want to maintain their position and value to the organization, and not feel undercut by the presence of new tools
  • Security and quality-minded engineers want to put in place guardrails (tooling and process) to ensure that a faster development pace does not come with security gaps, bugs, a collapse in code quality, or an inability for anyone to feel like they have a good mental model of the inner workings of the product

What we’d like to prevent

  • Good people from feeling their input or expertise is valued less than it used to be, by allowing the culture to drift too far towards just cutting and pasting in and out of LLMs to solve everything.
  • An inability for junior employees to be hired and rise up within an organization.
  • Losing the chance to build up institutional knowledge within an organization. Full ownership is impossible without full (or close to full) understanding. One cannot own what they cannot explain.
  • A view that all process or gate keeping is inherently bad.
  • Resentment building from engineers feeling like they’re being handed 100 poorly written or understood PRs every week from all sides, or that they have to play cleanup duty for PRs their product manager generated but can’t really do any quality control on.
  • Perhaps most obviously — a decline in product and code quality.

MCP usage example

MCPs allow for powerful connection between core services within an organization. As a contrived example, let’s say a back-end engineer is trying to deal with a problem of spiking database cluster resource usage during certain hours of the day. They could connect their LLM tool of choice to AWS, DataDog, Linear, and GitHub and ask the following to get a massive head start on the issue, perhaps while they themselves do some research on their own outside the LLM:

I was assigned the Linear ticket FDN-1234, to investigate an issue
around database CPU spikes. It seems to happen between 2-3pm EST every
day, starting a week ago. I have a theory that PR #12345 caused
the problem, as it added heavy parallelization to a thumbnail generation
Lambda function we know can be triggered by both the app and external
API calls. That PR hit production just before this problem started to occur.

Can you pull in the last 2 weeks of logs for the `product-api-prod`
ECS cluster and the `ThumbnailGeneratorLambda-prod`, along with metrics
from the `product-rds-cluster-prod` RDS cluster to back this up. It would be
good to get a sense for if there has been meaningful changes to traffic or
which endpoints are being hit at the same time this problem started, or if
things are consistent the last 2 weeks.

If needed, you can turn to DataDog as well to look for traces that might
point to the changes to `invokeLambda` in the PR above as a culprit, but
do not assume I am correct based solely on this hunch.

Provide your top 3 hypotheses and next steps.

This is a canned example of course, but it should demonstrate how much you can tie together — your code, your infrastructure/logs, your monitoring tools, and more — to quickly dive into difficult problems.

To product managers, designers, and others — here’s how to share your work

The tools at our disposal with pros/cons of each, ordered by how far or close they are to being code we can deploy to production. Use this guide to help in your decision-making when it comes to prototyping, sharing requirements, etc.

1. A ticket & conversation threads

Traditional requirements in the form of a spec or conversation thread

Use these most of the time! Remember that the engineer you’re handing work to has access to the same AI tools that you do, and a lot more understanding of the code base. Tickets are still the way to go 90% of the time, and can be augmented with context from a chat thread, mocks, etc. if needed.

2. High-fidelity mockups

Precise, static design assets

These are needed more rarely these days — only when extreme precision is needed, and it’s easier to sketch out via mockups than something interactive or looser. Should augment a ticket, not replace it.

3. Low- or no-code interactive mockups

Looser, faster to throw together mockups

As a way to augment any ticket that involves a workflow that is multi-step or spans across different components and pages. Tools like Replit, v0, and Magic Patterns are great for describing a workflow to and putting in place a web app that looks close enough to the real thing for the engineer to clearly understand.

4. Pull requests and sandbox environments

A fully functional deployed environment with the code to back it

A deployed environment has two clear use cases for a product person or designer. First, as the “ultimate” interactive mockup when a low-code or no-code tool isn’t precise enough, or the workflow you’re providing a spec for is too complex to re-implement or redesign. Leaves no requirements stone un-turned, but comes with the downside of potential struggles to get the code to build, an inability to debug anything on your own if the LLM can’t help you, etc. If you find yourself wasting your time or an engineers time just getting a thing working, it might have been better to just hand a ticket off to an engineer to dig into.

Second, as a way to make a pull request that is destined to be merged mostly as-is, or as a starting point for the engineer to run with. Reserve this for small, targeted changes that won’t force the engineer to rebuild your entire PR from scratch, but instead provide an actually useful jumping off point.