How I run product

The short version

Most scaling companies reach a point where informal ways of working stop scaling with the business. Growth was rightly prioritised over internal process maturity. That's the correct call in the early stages, but eventually the cost of misalignment between business and technology compounds. When that happens, the answer is not more process. It's the right process, introduced at the right weight.

The framework I install organises all product and development activity into two-week cycles with clearly defined stages from initial idea through to delivered feature. Business teams contribute during discovery and participate directly in prioritisation decisions. Technology reviews and estimates all work before it enters development. Product provides the connective tissue between the two, ensuring that what gets built is aligned with strategic goals and that progress is visible to everyone who needs it.

AI is integrated from the outset, accelerating competitor analysis, rapid prototyping, and business analysis. The framework's adaptability means it is not dependent on any specific tool; it is designed to absorb new capabilities as they emerge.

The goal is simple and measurable: within six months, the company can answer "when will this be ready?" with a confident, data-backed answer rather than a guess.

The challenge this solves

As customer numbers increase and product complexity grows, the cost of misalignment between business and technology teams compounds. Without a shared, visible understanding of what is being built and why, effort gets duplicated, misdirected, or delivered without the context needed to make it truly valuable. Business teams (sales, marketing, portfolio, legal) need visibility into what is being developed and when it will be ready, so that customer commitments, campaigns, and commercial planning can proceed with confidence. In regulated sectors, where legislative changes often dictate specific launch windows, this predictability is not a luxury. It is a requirement.

A significant proportion of operational process at this stage typically lives in spreadsheets. That works early on; it stops working as the business scales. There is often no unified data model underpinning systems, which means there is no normalised, reliable data source on which to build new products. Foundational records, such as a single view of the customer, do not yet exist in structured form. Without them, measuring how long customers spend in onboarding, identifying where bottlenecks form, understanding which segments need the most support, or confirming whether initiatives are having the intended commercial impact all become unreliable.

Equally, there is usually no documented set of workflows or quality standards governing how customer-facing products move from concept to release. When the detail of what needs to be built lives primarily in the minds of individual team members rather than in documented requirements, the business becomes reliant on the availability and interpretation of specific individuals. That creates bottlenecks, makes timelines difficult to predict, and increases the risk that what is delivered does not fully meet the needs of the business or its customers.

None of this reflects poorly on the team that got the company here. They are the natural growing pains of a business that has been correctly focused on growth and is now ready to professionalise how it builds and delivers products. The challenge is not a lack of technical capability; it is building the connective tissue between that capability and the outcomes the business is pursuing.

The framework

The approach is deliberately lightweight. It is designed to introduce discipline and visibility without creating bureaucracy, and is based on established product management practices that have been proven at scale, adapted to the company's current size and stage of maturity. As the company grows, the process grows with it.

Everything is organised into two-week cycles, which create a predictable rhythm that the whole company can plan around. These cycles govern how business teams, product, and technology interact, making it clear who contributes what, and when.

From idea to delivered feature

An idea moves through the system in a defined sequence:

Opportunity identification

Ideas and opportunities are captured on an opportunity tree: a visual tool that maps every opportunity against one of the company's business goals. This ensures that everything being explored has a clear link to what the company is trying to achieve, and prevents effort being spent on ideas that are not connected to strategic priorities. Business teams contribute opportunities alongside the product team.

Discovery

Before anything gets built, opportunities go through a discovery process involving data analysis, customer research, and rapid prototyping. The goal is to test whether an idea is worth pursuing and to understand the problem in enough detail to act on it. Discovery runs continuously throughout each two-week cycle, and an item must spend at least two full cycles in discovery before it can move forward.

That minimum exists because there is a meaningful amount of work that must be completed before an idea is ready for development: the product and business teams need sufficient time to conduct analysis, define requirements in enough detail to be actionable, and run the necessary prioritisation and planning steps. Two cycles is a realistic minimum for this to happen thoroughly. For genuinely urgent items it can be shortened, but as a default it ensures that what enters development has been properly considered. This prevents half-formed ideas from entering development, one of the most common and expensive mistakes a product team can make.

Prioritisation for further investigation

Items that have completed initial discovery move to a story map, where department heads collectively agree which opportunities should be investigated in more detail. This is the first point at which the business actively shapes what product and technology will focus on. Priorities are visible to everyone, and decisions are made together rather than in isolation.

Decomposition

Once an opportunity has been prioritised, the product team breaks it down into clearly defined units of work. Each unit describes what the user needs to do and why, along with specific criteria that define when the work is complete. This decomposition is critical for two reasons: it prevents scope from expanding uncontrollably once development begins, and it ensures that both business and technology teams have a shared, documented understanding of what "finished" looks like before a single line of code is written.

Technical review

The defined units of work are then reviewed by the technology team, who add the technical and implementation detail needed to build the feature. This is where feasibility is confirmed, technical decisions are agreed, and any additional information requirements are surfaced. Nothing proceeds into active development until it meets a defined standard of readiness: a developer can complete the work without needing to return to business or product teams for clarification. This standard of readiness is a quality gate that protects both the development team's time and the business's expectations.

Capacity planning and cross-company prioritisation

As part of the technical review, developers estimate the effort involved in each unit of work using a consistent scoring method. Over time, this produces a reliable, data-driven measure of how much the team can deliver in each two-week cycle. That measure of throughput is what makes it possible to commit to deadlines with confidence. Instead of guessing when something will be ready, we can forecast based on actual, demonstrated delivery capacity.

When deciding what gets built next, we draw a line on the development story map representing the team's available capacity. Everything above the line is committed to the current cycle. Everything below waits. When multiple departments have work that needs development, all items are placed on the same map. This means that a decision to prioritise an item for one department is visibly understood as potentially delaying an item for another. Trade-offs become transparent, shared, and jointly owned.

Department heads participate directly in this prioritisation. Decisions about what gets built are made collectively and in the open, rather than behind closed doors or based on who asks most urgently.

Delivery, visibility, and quality

Once work enters a two-week cycle, a short daily check-in between product and technology ensures that everyone knows what is in progress, what has been completed, and what is blocked. This is a focused ten-to-fifteen-minute session designed to surface problems early rather than at the point of delivery.

Nothing is considered complete until it meets the agreed acceptance criteria defined during decomposition. This prevents unfinished or inadequately tested work from reaching users or customers, and gives the business confidence that what is released has been built to the standard that was agreed.

Continuous improvement

At the close of each two-week cycle, the team holds a retrospective: a structured discussion about what worked, what did not, and what should change. Action items are assigned to specific people and followed up at the next session, ensuring that improvements are tracked and closed rather than simply discussed.

This matters: the framework itself is expected to evolve. It will not be perfect on day one, and no-one should expect it to be. The retrospective exists precisely because the process must be treated as a product, something that is continuously tested, measured, and improved based on real experience rather than assumptions.

How AI fits

One of the strengths of a lightweight framework is that it can absorb new tools without needing to be redesigned. AI is a clear example. To be clear: AI is not replacing any part of the process described above. It is accelerating specific stages where speed and breadth of analysis matter most.

In discovery

I use AI to support competitor analysis. It allows us to scan what similar companies are doing across different markets, identify patterns in competitor product offerings, and research the setbacks international competitors have experienced, so that we can anticipate known risks rather than learning from them the hard way. This kind of broad, rapid analysis would traditionally require significant research effort. AI makes it possible to do it continuously and at a fraction of the cost.

I also use AI for rapid prototyping. During discovery, product and business teams can use AI to create working front-end prototypes of the ideas being explored. This dramatically reduces the time between "we think this could work" and "here is what it would look like and how it would behave." Critically, these are not throwaway mockups. The AI is configured with guidelines that mirror the company's actual technology stack: the same language, frameworks, code conventions, and dependencies used in production. That means the gap between a prototype produced during discovery and a production-ready feature is significantly smaller than it would be with traditional prototyping approaches. It also means the output is technically realistic, grounded in what can actually be built, not just what looks good on screen.

In business analysis

I use AI to accelerate data and business analysis activities: breaking down complex data sets, brainstorming feature ideas, and retrieving and synthesising information from meeting minutes, strategic documents, and known issue logs. This is particularly valuable for a growing company where institutional knowledge is distributed across many people and documents. AI helps surface and connect information that would otherwise require significant manual effort to locate and interpret.

The broader point

The lightweight nature of the framework means it is not dependent on any specific tool or technology. AI enhances it today, but the framework itself is designed to accommodate whatever tools or changes in the business environment emerge in the future. As AI capability matures, additional applications will emerge naturally through the discovery process itself; the framework provides the structure to evaluate and adopt them in a controlled and deliberate way.

Early and purposeful adoption of AI in product management gives the company a genuine operational advantage over competitors still working with traditional, manual approaches to discovery and analysis.

How I measure success

Pilot and alignment

The framework is always piloted on one or two live initiatives already on the roadmap, real priorities that involve collaboration between product, business, and technology. That makes them a realistic test of the full framework rather than an artificial exercise. The goal within the first month is to reach full alignment between product and technology on committing to the framework, so that the first complete two-week cycles can begin. The pilot period provides the space to learn what works and make adjustments before the process is applied more broadly.

Pilots are evaluated on whether the framework delivers what it promises: visible progress, predictable timelines, and a shared understanding between business and technology of what is being built and why. Specifically, whether the team's throughput is measurable and consistent, whether the quality gates are preventing incomplete work from reaching customers, and whether business teams feel meaningfully involved in shaping what gets built.

What success looks like at three months

Within three months of the first full cycle, the company should have a structured backlog in place. The next six weeks of work should be fully detailed, reviewed by the technology team, and estimated for effort, meaning it is ready to be built. The six weeks of work beyond that should be defined and ready for technical review. Critically, by this point we will have the first real data on the team's delivery throughput: an actual, measured understanding of how much work the team gets through each cycle. This is the foundation on which everything else depends. Without this data, timelines are guesses. With it, they are forecasts.

What success looks like at six months

Within six months, the company should have a twelve-month backlog with a clear gradient of detail. Items planned for the next three months should be ready for development. Items planned for three to six months should be defined but not yet technically reviewed. The remaining six months should be captured at an epic level: high-level descriptions of intended capability with minimal detail, to be broken down as they approach the development horizon.

At this stage of a scaling company, the challenge is rarely finding enough work to populate the backlog. The volume of work required usually significantly exceeds the capacity of the existing development team. That is precisely why the framework's prioritisation discipline matters: with more work than can realistically be delivered, the ability to make visible, informed decisions about what gets built first, and what does not, becomes essential. By this point, the team's velocity should be reliably demonstrated, meaning we can commit to specific delivery timelines with confidence and have honest, data-driven conversations about capacity when they are needed.

The simplest test

The clearest measure of success is a simple one: can the company answer the question "when will this be ready?" with a confident, data-backed answer rather than a guess? If yes, the framework is working.

Beyond this, success looks like visibility across the business into what is being built, what is coming next, and why specific trade-offs have been made. It looks like business teams (sales, portfolio, legal, and eventually others) actively contributing to discovery and prioritisation, rather than submitting requests and waiting without clarity on when or whether they will be addressed.

Scaling the team

Most scaling companies are missing roles that are standard in a modern product development function. These gaps do not prevent the framework from being piloted. The process can begin with the team as it stands today. However, one of the benefits of the framework is that it generates the data needed to identify exactly when and where additional capability is required, allowing these decisions to be made based on evidence rather than assumption.

As throughput data becomes available and the development pipeline becomes more visible, it will become clear where the constraints are. If quality issues begin to increase (features requiring rework after release, defects reaching customers), that is a signal that dedicated testing capability is needed. If development is slowed because requirements lack sufficient visual detail for business teams or customers to evaluate, particularly for customer-facing products, that points to the need for design capability. If technical decisions are creating delays or inconsistencies across the codebase, that indicates the need for a dedicated tech lead who can provide architectural direction and ensure consistency across the team's output.

The framework will surface these signals clearly and early. When they appear, they can be prioritised through the same transparent process used for all other decisions, with the data to support the case and the visibility to understand what is at stake if they are not addressed.

Looking ahead

As the process matures and visibility into the development pipeline improves, it will naturally surface dependencies on foundational technical decisions, areas such as architecture documentation, data strategy, and security policy, which will need to be addressed to support the next phase of growth. The framework itself makes these dependencies visible and quantifiable, allowing them to be prioritised through the same transparent process used for all other work.

· End ·