How do you assess whether a Product Engineering team is ready to use AI?

Teams often ask whether they are “AI ready” as though readiness were a maturity score. In practice, a team may be ready to use an assistant for bounded test generation but not ready to give an agent access to several services. The decision depends on the work and the authority being proposed.

A short readiness assessment helps leaders avoid two mistakes: delaying all learning until every organisational issue is solved, or enabling powerful tools before the team can detect and contain failure.

Define the problem and accountable owners

Begin with the delivery constraint or opportunity. It might be repetitive test preparation, slow investigation of routine defects, documentation that falls behind or a queue of well-understood maintenance changes. Describe the current workflow and why improving it matters. “Use AI” is not an outcome.

Product should be able to explain the intended value and acceptable effect on customers. Engineering should own the technical approach, quality, architecture and operability. Name the person responsible for the trial and the people authorised to accept its outputs. Include security, privacy, risk or platform expertise when the use case reaches their domains.

Check whether participants have time to learn, review and report honestly. A trial added invisibly on top of full delivery commitments is likely to produce rushed oversight or shallow evidence.

Assess the work and engineering environment

Suitable first work is usually bounded, understandable and reversible. The team should have representative examples, clear acceptance criteria and a way to compare the AI-enabled approach with current practice. Avoid starting with novel, highly coupled or high-consequence work simply because it appears valuable.

Examine the feedback available to both people and tools. Version control, dependable builds, automated tests, code review, deployment controls and operational monitoring make mistakes easier to see and recover. Weakness in one area does not automatically prevent a trial, but it changes which work is safe and what must remain human-led.

DORA’s 2025 research describes AI as an amplifier of the surrounding organisational system. This supports a practical conclusion: introducing AI will not reliably compensate for unclear work, poor feedback or fragile delivery. Those conditions may become more visible and should be treated as part of the experiment.

Establish minimum data and control boundaries

Confirm which tools and models are approved, what information they may receive, where data is processed and retained, and which repositories or services they can access. Protect secrets and customer information. For agents, separate read, write, execution, merge and deployment permissions rather than granting a broad role.

Define required review, tests, approval points, logs, stop conditions and recovery. Higher consequence and greater agent authority require stronger controls. NCSC guidance places secure AI work across design, development, deployment and operation; readiness should therefore include the delivery environment, not only model selection.

Record unresolved issues. A missing policy for sensitive source code may block that use but still permit a sandbox exercise with synthetic data. Make exceptions explicit rather than allowing the pilot to define policy accidentally.

Make a use-case-specific decision

Conclude with one of three decisions: proceed within stated boundaries, prepare and reassess, or do not proceed with this use case. List the evidence behind the decision and the conditions that would change it. Avoid averaging several dimensions into a score that hides a critical weakness.

If preparation is needed, keep it proportionate. Improve a targeted test suite, create a sandbox, clarify data handling, establish a baseline or train reviewers. These investments may improve normal engineering as well as the future trial.

Readiness expires when the task, team, tool, permissions or environment changes materially. Reassess before expanding from an assistant to an agent, from one repository to many, or from development into production. The useful question is always whether this team can learn from this use case while protecting the product and retaining accountable judgement.

Example

A product team wants to trial AI against a backlog of routine accessibility fixes. The work has clear acceptance criteria, automated interface tests and straightforward rollback. Product owns the customer outcome, while an engineering lead owns technical acceptance.

The team approves a repository-scoped assistant but excludes customer analytics data. Engineers review every change and record rework, defects and time spent. An agent that can merge changes is deferred because permission and audit controls are not ready. The team proceeds with the narrower trial rather than labelling itself fully ready or unready.

FAQs

• Does a team need an AI strategy before it can run a trial?

  Not necessarily. It needs an authorised purpose, clear boundaries and alignment with relevant organisational policies. Evidence from a controlled trial can inform a wider strategy.

• Does weak automated testing mean the team cannot use AI?

  It limits which uses are sensible and increases the need for other verification. The team may first improve targeted tests or choose work where outcomes can be checked reliably.

• Who should perform the readiness assessment?

  Product and Engineering should lead it together, involving security, privacy, architecture, risk or platform specialists according to the proposed data, tools and consequences.