What a 90-Day Product Engineering Engagement Looks Like

When I describe what CAM Software does, embedded product engineering leadership, the words are accurate but abstract. The most useful thing I can do is explain what we would actually do, how we would know it helped, and what has to be true before we leave.

The initial operating window is usually 90 days, but the product I am selling is not a calendar. It is one defined outcome for one product and one team, with the leadership and hands-on implementation needed to move it. Ninety days usually gives us enough time to understand the real system, implement something meaningful, observe it through real work, and transfer ownership. It is not a promise that every product follows the same schedule.

---

What happens early in the engagement?

We spend time with each member of the core team, one at a time. Not a survey, actual conversations. And something consistent happens in them: because we're a third party with no history inside the company, people are a lot more open about their frustrations than they are internally. That candor is data you cannot get any other way.

The other thing that surfaces in these conversations is ideas. Sometimes a person has had a good idea for a while and been afraid to voice it, for one reason or another. When one of those ideas is right, we say so, we credit it, and we help implement it. Some of the most valuable changes in an engagement started as something a team member had been quietly carrying for months. Fresh eyes help here too: even when you don't like our ideas, that's one less idea you have to wonder about, and sometimes an outside idea turns out to be more powerful than anyone expected.

---

What changes during implementation?

Once the evidence supports a priority, we start implementing. I am not going to sit on useful work to protect a phase boundary. The business should be able to see what the team is already doing well, what is actually getting in the way, which outcome we are moving, what the baseline is, and which evidence will tell us whether the change helped.

As the new flows begin running, I watch for questions from outside the immediate team: things another team noticed, improvements that would help more than one group, or people adopting the new process without being pushed. That cross-team pull is a useful signal because it means the changes are becoming the company's rather than ours. This is also where a lot of the practical enablement happens, like teams keeping tickets and wikis current as part of the work itself, and product owners getting better visibility into what is actually moving (I've written about giving PMs and POs real visibility).

If your team currently has none of this structure, that's not a disqualifier. It's the starting condition I see most often (here's what usually happens without it).

---

How does the engagement end?

Transition starts early enough for us to test whether it actually holds. One of the most important jobs is finding the person on your team who will own this going forward. In my experience that person can be anyone from your most junior developer to your most senior. It comes down to context, support, and drive. When we find them, we recommend them openly, and with your permission they get real ownership while there is still time for us to support the handoff.

Two boundaries are worth stating plainly. First, staffing decisions are always yours: we surface what we observe, including hard observations, but who is hired, moved, or let go is a decision your executives make, and recommending someone's removal is a last resort, not a first move. Second, if nobody is ready to take ownership, we do not pretend the handoff is complete. We make the gap explicit and decide whether to narrow the exit, define a new scope, or bring in the permanent ownership the product needs.

We believe in finding the best plan, not the plan that makes everybody happy, so at some point in the engagement we will probably make someone unhappy. What I've found is that when a decision is made through a real process, even people who disagreed with it tend to come back later and say it helped, because when the unexpected scenario showed up, there was a process for it.

---

How do you know if you need this?

Three situations account for most of the engagements I see. You inherited a product, or had one built by an offshore or third-party team, and now it needs to come in-house with structure it never had. Or you have a team that has been working hard for a long time without the product actually moving forward. Or, maybe most common, decisions just aren't getting made: capable people with conflicting perspectives and no mechanism for landing on an answer, so nothing gets decided at all.

If one of those sounds like your situation, the process page has the full arc, and the engagement details cover how the commitment is structured. These are general thoughts drawn from how the engagements have actually gone, and every company is a little different. But the shape holds: listen first, build the structure with the team rather than at it, and leave behind an owner instead of a dependency.