EiQ by LRQA · Hong Kong · 2024 — Present
Product operating rehab
Re-architecting product, engineering, workflows and delivery models around outcomes and measurable commercial value.
Context
A data-heavy platform business with fragmented workflows, delivery friction and untapped commercial value in its data.
Intervention
- Aligned product, engineering, data and operations around one delivery model.
- Reorganized teams into agile, cross-functional squads with clear ownership.
- Moved AI from experimentation into high-value operational workflows.
Outcome
- Scalable platform-development model.
- Clearer accountability and cadence.
Rehabilitating the way product and tech work
Before the change, work arrived ad hoc, focus shifted constantly, users were involved only at the end in waterfall style, solutions were imagined internally with customer needs assumed, and nobody measured whether anything got adopted. Management roles overlapped and technical debt absorbed whatever capacity was left.
The rehab moved the organisation to agile, product-led, customer-centric operations in three deliberate phases — alignment first, then ownership, then agility — with a single product development pipeline, a mandatory PRD standard, and a discovery practice that starts from customer problems rather than internal opinion.
The three phases
1. Phase 1 — alignment · Q2 2025
Able to focus and deliver on time. Work routed via customer-centric value streams, focus enforced, clear commitments at release with resources assigned and broadcast.
2. Phase 2 — ownership · Q3 2025
Able to innovate and iterate for the customer. Discovery structured by product owners with dev leads, customers included in design phases, releases committed across multiple horizons.
3. Phase 3 — agility · Q4 2025
Delivers significant value with minimal oversight. Focus designed in, discovery co-designed with clients, weekly committed releases, a learning organisation measuring adoption and decision quality.
Discovery as a discipline
Priority, then ownership, then discovery: an announced start, a four-to-six week investigation built on customer surveys and calls, CSM workshops and SME review, running in parallel with a high-level technical design. It closes with a published PRD reviewed by external SMEs from business and engineering — three to four sprints end to end.
What a PRD must contain
- Definition, breakdown and informed assumptions around the business problem.
- Proposed solutions and identified dependencies across platforms.
- Estimated costs and benefits of solving the problem.
- Technical dependencies.
- KPIs to measure success.
The pipeline, phase by phase
Prioritisation
A fast-moving, regulated industry means the list must be re-cut regularly.
New Product Item Proposal process, reviewed weekly by business and technology leaders.
Discovery
Problems and solutions must be thought through and owned by the right competency.
Announcement, 4–6 weeks investigation (surveys, CSM workshops, SME input), publication. Product owners and engineering leads, monthly cadence.
Alignment
One decision across product, software, DevOps, QA, data and infrastructure.
A PRD per priority: business impact, technical breakdown, optional MVP/pilot phasing — signed off by every function.
Planning
Once an item is clear and aligned, position it into delivery sprints.
Monthly and quarterly planning on committed benefits and costs.
Delivery
A committed release date, communicated widely.
Synchronised sprints with joint planning and review across squads.
Go-to-market
Adoption is the deliverable, not the release.
Training material, manuals and maintenance plans; market feedback woven back into the pipeline.
How a new priority enters the system
- 1.Anyone with an idea submits it through the Product Item Proposal form. Nothing enters the roadmap outside that process — no random emails.
- 2.A product committee reviews every undiscussed item each Monday against a prioritisation framework: growth cycle, market research, customer expectations and real capacity.
- 3.Every submitter gets a decision — 'not a priority', or a priority with an expected quarter of completion.
- 4.'Not a priority' items are revisited quarterly. Maximum ten business days to an answer.
A discovery wave, end to end
High-level definition of content
Set the discovery timeline and align on the long-term vision.
Validate with clients
Build the UI concept, run a customer survey or roundtable, and play the prototype to clients by piggybacking the early-adopter programme.
PRD drafting
Starts from the product item definition and bridges to go-to-market. Audience is the technical community: client problem, feature definition, user requirements.
PR and HLSD drafting in parallel
An internal release narrative for commercial teams and leadership, plus the technical definition of the solution and its dependencies.
Planning
Both documents converge into sprint planning.
New ways of working
Release pack
Every release ships with three standard documents — a go-to-market one-pager, a feature deck for sales and CSMs, and an internal FAQ — published 7–10 days before launch for team feedback.
Discovery consultation
Every new PRD opens with a structured ideation workshop so the team shapes the solution collectively before design begins.
Weekly leadership report
A high-level summary after every scrum of scrums, giving leadership full visibility across all 11 active streams.
SAGA feedback framework
Feedback is consultative: Specific, Actionable, Greenlight-oriented, Assuming the best.
The organisation behind it: focus, accountability, speed
- A dedicated CTO owns the full technology vision with authority over product engineering, platform architecture, data infrastructure and technical operations.
- Engineering restructured into four product-focused squads, each aligned to one problem space — Intelligence, Connectivity, Collaboration, Autonomy — owning its domain end to end, from problem definition through delivery, with the product owner inside the squad.
- Shared platform, DevOps and data-engineering capability sits underneath the squads rather than inside any one of them.
- Governance through quarterly alignment with group technology leadership: strategic coherence and executive visibility without constraining delivery velocity.
- Delivery objectives are unambiguous: ship continuously, validate fast, build for market readiness from day one — idea to working MVP within a day, iterate in the open, invest in go-to-market polish only once signal is proven.
- We measure ourselves by what is in users' hands, not by planning cycles: velocity, release frequency and time-to-value.
Principles
Most ideas fail for being wrongly executed.
- We are one team, even though no one contributes the same way — as it should be.
- Humility will save us all: acknowledge failure and iterate fast to get better.
- It is always about the customer.
transformation · org design · AI adoption