Carlo Caprini
Menu
Work

Working through difficult Product & Engineering problems.

I occasionally work with software teams when a product, technical or organisational problem has become difficult to reason about from inside the system.

The aim is to understand the problem, make the trade-offs visible and leave the team with something useful to act on.

Where this tends to be useful

When the problem crosses boundaries.

  1. Releases keep getting harder

    Small changes increasingly require coordination, manual checks or risky deployments, and the team is losing confidence in what a “safe release” actually means.

  2. The team knows something needs to change, but disagrees on what

    Architecture, process and product priorities have become mixed together, making it hard to decide where to intervene first.

  3. Technical decisions are starting to constrain the product

    What used to be an implementation detail is now affecting roadmap choices, customer requests or the team's ability to change direction.

  4. The system is accumulating changes faster than confidence

    New capabilities keep shipping, but testing, architecture or delivery practices are not keeping pace with the rate of change.

  5. A platform or API needs to evolve without weakening what already depends on it

    Product opportunities, developer experience and technical compatibility need to be considered together.

  6. AI adoption is creating activity, but not yet dependable improvement

    The team has tools, prototypes or agent workflows, but it is still unclear what should be automated, what should remain human-owned and where reliability actually matters.

The answer is not always more automation or more AI. Sometimes the useful decision is to keep a workflow explicit, manual or human-owned.

Product & Engineering Review

Understand the system before changing it.

The goal is not to find as many problems as possible. It is to understand which problems matter, which ones can wait and what is already working well enough to preserve.

What I may look at

Depending on the problem:

  • Product & Engineering context
  • Architecture and codebase structure
  • Testing and quality practices
  • CI/CD and release practices
  • Development workflows
  • Product & Engineering interfaces
  • Platform and API evolution
  • AI-assisted development where relevant

Depending on the problem, I may look directly at repositories, tests, CI/CD configuration and technical documentation, not just interviews or presentations.

Outcome

A structured assessment connecting the most important findings to supporting evidence, priorities and recommended actions.

  • Executive assessment
  • Prioritized findings
  • Supporting evidence
  • Risks and opportunities
  • Recommended actions
  • Final walkthrough
Product & Engineering Advisory

Work through the changes together.

Focused ongoing support when the problem cannot be usefully reduced to a single review.

Typical areas

  • Product & Engineering direction
  • Platform and API evolution
  • Software delivery and engineering practices
  • Product & Engineering collaboration
  • AI adoption and AI-assisted development
  • Follow-through on findings from a Review

This can mean

  • Reviewing a proposed architectural change before implementation
  • Working through competing Product & Engineering options with the team
  • Helping prioritize Review findings into incremental changes
  • Revisiting a release or testing strategy before investing in a broad rewrite
  • Evaluating whether an AI-assisted workflow should be automated, constrained or left alone
How I work

Three principles for working through the problem.

Recommendations should follow understanding rather than precede it.

  1. Understand the system before recommending changes

    Start from the existing product, software, architecture, processes, constraints and the decisions that created them.

  2. Work from evidence, not only opinions

    Depending on the problem, this can include repositories, tests, CI/CD configuration, technical documentation, architecture decisions and conversations with the people closest to the system.

  3. Review the system, not the team

    The purpose is to understand the system, not to grade the people who built it. Existing decisions should be considered in the context and constraints that produced them.

Experience behind this work

Experience across Product & Engineering.

I started in software engineering and have spent more than a decade working across product management, APIs, platforms and developer-facing software.

  • From software engineering to product management
  • B2B platforms and APIs
  • Startup and global product organisations
See full experience
What happens next

Start with the problem, not a package.

Send me a short description of what is getting difficult.

If I think I can help, we start with a short conversation to understand the context and decide whether a focused Review or Advisory engagement makes sense.

If a Review is useful, we agree on the question to answer and the minimum context needed, such as repositories, documentation and conversations with the people closest to the system.

If I am not the right person, I will tell you.

Start a conversation

Have a problem like this?

Tell me what is getting difficult.

If you are working through something similar, send me a short description of the problem.

Based in Italy, working with software teams in Italy and internationally.

Start a conversation