Daniel Dalton

Software engineering for product managers

image

Update 2026/08/11 - I realized I got this the wrong way around. Probably the more interesting angle to explore first is why and when it might be useful for product managers and designers to do software engineering (that is, working in code with others and the processes around it). This piece is more of the how. But I will work on the why and when next and keep you all updated :)

Get access to stuff you need access to

This might be the hardest part of starting your software engineering journey. Local dev setups are notoriously poorly documented, mostly because it's easy for them to get out of date (stale) quickly. If you already have an internal LLM setup, ask it to do it for you. If your organization doesn't have an internal LLM setup, pause here and go talk to your IT team now.

You’ll know you have the access you need when you can:

Learn the basics

LLMs can do pretty much everything except tie your shoelaces if you give them the context and tools. But taking the time to understand things like your organization’s CI/CD pipelines, internal dependencies, platform stuff (and what those terms mean) will help a lot in doing good work in the software engineering domain. Ask an LLM to explain concepts where you’re not sure.

Learn a little bit of Git - just pulling from main, creating a branch, and pushing to your branch on remote is enough. You should not have to rely on an LLM to perform these basic operations (you probably will, but you should not have to). They are core to contributing to a codebase in organizations of any size.

If you have some domain expertise, you’ll be much more impactful with LLMs than someone who doesn't.

Provide added value

Don't be a meat proxy. You need to add value as the human in the loop. Otherwise, what are you there for?

Use your own words when in discussions, and be a thoughtful filter to the LLM output. This is especially important in the human interaction parts of software engineering, like explaining what you’re trying to do and why you’re doing it, and how you (or the LLM) have done it. Even if most of your context and knowledge is coming from a conversation with an LLM, framing it in your own words helps make sure you’ve understood it, and people appreciate hearing it in your voice.

Follow engineering etiquette

Your team will have its own culture and style for making changes. Look at examples of how they’ve done it and follow the pattern. This is referring to things like the PR description, structure and content.

In addition to the typical structure, take the time to document your changes with screenshots or a recorded demonstration. As a product manager or designer, you should be great at this, and it’ll make your reviewer’s life easier and consequently much quicker to get your changes in. Show the before and after state as part of your demonstration, providing proof that the change is working as intended.

Finally, divide your changes into smaller atomic units and make separate pull requests for each of them. With this engineering etiquette in place you will have a smoother path to getting your changes merged, and happy engineering reviewers.

Learn as you go along

Not being a software engineer in title does not exempt you from learning if you are contributing code, and if you’re reading this, ideally you’re eager to learn. Every time an engineer reviews your work and offers feedback, they are taking time to invest in your future growth. Absorb those lessons, and make sure future changes reflect them.

Ideally you understand how an LLM has implemented the thing you’re changing. But if not, make the effort to understand at least the broad strokes, enough to be able to have a discussion with an engineering reviewer.

LLMs already help build things much faster than you could have otherwise, so put some of that time back into learning what’s being done and you’ll be much better off for it in the long run.

Stick to established patterns

If you find the changes you’re making are establishing a new pattern, or making architectural decisions, it’s a sign that the change is not a good fit to be product manager/designer led.

You can contribute more confidently where the architecture to accommodate your change is already in place. Learn to identify when new patterns or architecture are being introduced by an LLM. Where you’re not sure, ask.

Refer to lines of code as a heuristic for reviewing effort

You won’t be the best judge of what is simple to review and what isn’t, but you can use the diff, the lines of code added and removed, as a good heuristic for the amount of effort it will take an engineer to review your changes. More lines changed, more effort.

Then you can calculate an impact-to-lines ratio for a given change before sharing it for review. A low ratio, many lines changed for a not-so-impactful result, is a signal that either the change isn’t worth making, or the LLM has been overly verbose, or worse, has been overly eager and touched parts of the codebase not in scope for the change. In these scenarios you can prompt it to redo the change more simply or challenge the scope.

Let me put it this way: alarm bells should be ringing if you’ve asked to add a tooltip and you see a 500-line diff.

Distinguish shipping from prototyping

Recognize when you’re working on something complex where the code will be hard for you to parse, but will do a better job of demonstrating the behavior and output than a PRD or Figma.

Prototype code exists to communicate behavior. It won’t ship as-is, and shouldn’t be judged as an implementation. A good example is something like demonstrating desired behavior in canvas interactions between left click, right click and select state over different types of nodes and edges. “What happens when you do X then Y then Z? What about Z then Y?”

This is in contrast to a polished, tightly scoped change that you do want shipped to prod.

Understand when not to write the code

Before, anything you wanted built as a product manager required convincing someone to build it. Today, most things are a prompt or two away. But you should still do that exercise, even if you don't have to anymore, because establishing the problem and the pain you're trying to solve is a pre-requisite to figuring out the best solution (and whether that's found in the code or elsewhere).

Framing also helps here, so make it clear where something is a prototype you’re exploring and looking for feedback on versus a change you’ve validated to ship ASAP. And if the latter, show your work.

Remember it’s a partnership

The advent of LLM-assisted coding offers another avenue for product managers and software engineers to continue collaborating and learning from each other. LLMs lower the barrier to entry to contribute code, but it’s ultimately your engineering team’s domain and responsibility to maintain, and they are on the hook when something breaks at 3 AM.

That’s important to remember when you feel like an amazing change you're driving is being sandbagged. It’s frustrating to feel blocked on something you’re confident already works, and it’s natural to read that friction as unnecessary. But you’re only dealing with the tip of the iceberg as the engineer reviewing your change today is optimizing for the person reading it in a year with none of this context, so there’s an understandable interest in taking the time to write, rewrite, and perfect it.

Code is written once, but read many more times

— Guido van Rossum

We have a lot to learn from each other. Ignore limits imposed by title or domain and keep learning. LLMs are an incredible tool not only for pushing out work you don’t understand fast, but also for learning and absorbing concepts faster than you could have otherwise. Keep learning, keep growing, keep making thoughtful contributions in code and otherwise, and you’ll be well on your way to being a good (adjacent) software engineer and an effective collaborator with your colleagues.