How I work  ·  A point of view

Understand the business before you change a thing.

A working view of how I approach a transformation from day one - what the first ninety days look like, where the real value tends to sit, and what an AI-optimised operation can become. Method, not theory: it is the same craft I have used supplier-side and business-side for over a decade.

Why this
exists

Conversations about a role usually start with a CV. I would rather start with the work. This is how I approach a transformation from day one, set out as a structured way of thinking rather than a list of credentials.

Nothing here assumes inside knowledge of any one business. Treat it as a sample of how I would approach the work from the start, and as something to pressure-test against the reality of your own operation.

01 / APPROACH

The first 90 days: understand before changing anything.

Transformation goes wrong when it starts with the solution. The first quarter is for earning the right to recommend anything at all.

Weeks 1 – 3 · Listen and map

Understand the business as it really runs

Discovery interviews across every function that touches the work - operations, finance, commercial and IT. Shadow the reporting and month-end cycle end to end. Document the real workflows, not the org chart, and confirm the true system of record, the integrations around it, and where data still moves on spreadsheets and email.

Weeks 4 – 8 · Find the friction, size it

Separate interesting from material

Identify the handful of processes that consume the most manual hours, carry the most risk, or slow the most decisions. Each one quantified in hours and money, so priorities are argued with evidence rather than instinct.

Weeks 9 – 12 · Sequence the wins

A roadmap leadership can stand behind

Two or three quick wins that build credibility inside the first quarter, set against the larger structural moves that take longer. Measures of success agreed with leadership before a single thing gets built.

02 / TARGETS

What good looks like, in numbers.

Transformation without a number is just activity. Every goal should map to an outcome the business already cares about.

  • Faster, cleaner reporting cycles - a monthly lag brought down to under 24 hours.
  • Less manual effort - administrative and reporting time cut by around a third, freeing skilled people for analysis rather than data entry.
  • A single trusted view - ten or more disconnected processes and spreadsheets pulled into one source of truth.
  • The metric that matters, moved - a target KPI lifted by a defined margin, such as conversion from 8% to 25%.
  • Every goal owned and measured - a baseline, a target and an owner, never left aspirational.
03 / BOTH SIDES

I have sat on both sides of the table.

Most people in this work have only ever seen it from one side. I have built the software as the supplier, and I have run the transformation as the business. That changes how I read a problem.

Supplier-side

At ISB Global I built enterprise software for clients turning over a billion-plus, owning the requirements and backlog for systems that served millions of customers. I know what engineering teams need to hear, and what quietly slows them down.

Business-side

At Asilia Africa I ran the transformation from the inside across fifteen businesses, owning the very systems I relied on every day. I know what it feels like to be the customer of a project that overran, or the user of a tool nobody adopted.

So when I sit down with your team, I am translating in both directions at once: turning the operation's real problems into something engineering can build, and keeping what gets built grounded in the work it is meant to serve.

04 / BACKLOG

Turning the problem into something a team can build.

A backlog only matters if it delivers value. Every story on it is there because it moves a business outcome, not because it was next in line.

  • Discovery and refinement - continuous conversations with the business to keep the backlog stocked with problems worth solving, not just tickets waiting to be picked up.
  • User stories and acceptance criteria - written so a developer can build without guessing and a tester knows exactly what "done" means.
  • Prioritisation against business outcomes - every story earns its place in the sprint by the value it delivers, not who shouted loudest.
  • The customer voice at the table - representing the end user and the business case directly to engineering, so trade-offs get made with the right information in the room.
  • Sprint and Kanban rhythm - planning, stand-ups, reviews and retrospectives run as a discipline, not a formality, with backlog health tracked as closely as delivery.
  • Demoing to the client - showing working software on a regular cadence, so feedback shapes the next sprint rather than arriving at the end.

This is the day-to-day craft behind the case studies elsewhere on this site, formalised through the Scrum.org Professional Scrum Product Owner I certification.

05 / WHAT YOU OWN

Get the most from the systems you already have.

Most organisations sit on more capability than they use. Before anyone buys something new, the bigger opportunity is usually switching on, configuring and connecting what is already licensed.

□
Map the full footprint - which modules are live, which are licensed but dormant, and every satellite spreadsheet quietly feeding or bypassing the core system.
□
Tackle accumulated complexity. Long-lived environments gather legacy dependencies, one-off reports and ageing integrations worth rationalising.
□
Audit the integrations and handoffs. The seams between systems are where most manual effort and risk tend to hide.
□
Standardise the data model - one definition of a customer, a contract, a site - before automating anything on top of it.
□
Switch on the AI that already ships in your tools. Document classification and extraction are built for the work still being keyed by hand.
□
Establish data governance and a human-in-the-loop standard before scaling automation.
□
Build internal capability and training, so the improvement outlives any single hire.
06 / THE AI OPPORTUNITY

What an AI-optimised operation can look like.

The striking part of most AI conversations: much of the capability already exists inside tools the business has bought. The work is enabling, configuring and trusting it, not buying something new.

Document processing

Days of keying become minutes

Intelligent classification and extraction turn the manual handling of invoices, contracts and forms into minutes of work, with a person validating the edge cases rather than typing every field.

Agentic workflow

Closing the gaps between systems

Where work stalls in the handoffs between systems - copying, re-keying, chasing across tools that do not talk to each other - agents can carry it across and complete the multi-step task, with people keeping oversight and control.

Audit-ready reporting

Compliance data captured at source

Energy, emissions and compliance data captured where it is created and surfaced into reporting that stands up to audit, rather than chased manually each cycle.

Ask your data

Answers without the report queue

A natural-language assistant that answers straight from the operational data - exposure, expiries, performance by segment - without waiting on a custom report.

None of this is theoretical for me. The same pattern - take a manual, six-week reporting process and rebuild it as near real-time, automated, AI-assisted reporting - is exactly the work I delivered as Product Owner for Trace, Amazon's sustainability platform, across a 500-plus site rollout, and across fifteen businesses at Asilia Africa.

07 / FIT

An honest word on fit.

What I bring
  • Ten-plus years turning operational mess into scalable systems, supplier-side and business-side
  • Product Owner on a sustainability platform across 500-plus sites, integrating logistics and operational data across the value chain
  • Full CRM, billing and operations lifecycle integration for two-million-plus customers and 100,000-plus contracts
  • Digital transformation across fifteen businesses, eliminating 500-plus hours of manual reporting a month
  • A daily, practical AI and automation practitioner - Claude, ChatGPT, Copilot, Make, Zapier - not a spectator
The honest part
  • When a domain is new to me, I will say so plainly rather than pretend otherwise
  • The engine of any transformation role is the same craft: discovery, requirements, integration, reporting automation, stakeholder facilitation and AI delivery
  • Domain context is learnable in weeks; that craft is the work of a decade, and it is already in place

The fastest way to judge fit is a conversation about where the real friction sits.

Most of that, of course, needs to come from you. I am happy to talk it through whenever it suits, and to pressure-test any of the thinking above against the reality inside your operation.

David Brien davidbrien@gmail.com linkedin.com/in/davebrien +27 82 328 0810