The Anatomy of RME

The simple anatomy of the RME concept starts with its definition.

Relevant: Measures and shows how closely the product is aligned with end-user needs.

Market: Denotes the targeted stakeholder mix and user groups. 

Exposure: Measures the duration of time that end-users actively use the product. Your product's exposure is zero if many users don't actively use it (hence only tracking Time-to-Market is not enough to grow the product). 

To relate RME with the traditional Time to Market (TTM) metric, TTM primarily considers the promptness of productionizing. In contrast, RME adds another monitoring layer, i.e., real-time relevance of the product to ensure its constant evolution.

While TTM is a good linear metric, a more dynamic product success metric like RME could take your product management chops to the next level.

Low-Code No-Code & RME

In the product lifecycle, two phases determine the nature of the user-product relationship: Pre-Go-Live and Post-Go-Live. 

RME in the Pre-Go-Live phase depends on various sub-phases such as requirements, design, development, and QA. One secret to a high RME involves embedding Low-Code/No-Code or Citizen Development tools early in the application development process. 

Similarly, RME in the Post Go-Live phase largely depends on product adoption and change management. A mindset to embed business-user-friendly Low-Code/No-Code tools in the Pre-Go-Live phase is critical in increasing RME. Further, it is easier to incorporate real-time feedback in the Post-Go-Live phase if a team uses Low-Code or No-Code tools to build apps.

Scenario One

Our team led a customer project where we automated a large-scale asset procurement process end-to-end. 

Run in a hybrid Agile mode; this program combined many complex use cases in a single functional flow with a high degree of business stakeholder engagement – a rare sight in most technology implementations. 

However, this model of cross-functional team collaboration came with its troubles, mainly in the form of analysis paralysis. The business's eagerness to iterate and define requirements at the lowest level of detail resulted in budget overruns in the first few weeks.

Our joint vendor-customer program team pivoted brilliantly to bring the low code no code platform into the requirements definition phase. Our program quickly gained RME upfront as the end-users got increasingly familiar with the tool. We fine-tuned the process by blending business participation with functional mock prototyping and proofs of concepts on the tool while some team members ideated the needs and stories. 

High exposure and relevance were achieved upfront, even before the product hit the market. The team also implemented Early Business Testing (EBT) to gain more exposure and increase relevance. We solved the usual issues of adoption and evolution upfront by bringing in a representative user group in the pre-go-live phase. 

The project is currently in a rhythmic release cadence with the business users engaged in every phase of the lifecycle, continuously evolving the product with a high RME.

Scenario Two

We now paint a futuristic picture by fusing the concept of citizen development in the low-code no-code domain with RME. Here is a vision regarding how the future PDLCs will be run:

1. The product development lifecycle of the future will eliminate the 'requirements definition phase. As the citizen developers, the business end-users will leverage the platform directly as a sandbox to develop POCs that will act as the iterative components for the functional and technical design of the final product.
2. Test-Driven-Development (TDD) will be replaced by Business-Driven-Development (BDD), where traditional business analysis, build, and quality assurance will all happen seamlessly, organically embedding the entire lifecycle with a high RME.

SMEs would still drive complex functionality and architecture in the tech domain, but these would act as enablers to citizen development and effective app governance. 

The success of the RME framework depends on a few Critical Success Factors (CSFs):

Critical Success Factors (CSFs) for Better RME

1. Mature fusion teams: This is a Gartner concept that stresses the need for multidisciplinary fusion teams, instead of organizing work by responsibilities within business functions. In our RME stories, these teams would potentially comprise citizen & professional developers, fused BA & QA SMEs (from the business) along with other critical roles for the implementation.
2. A mature Citizen Development Program: This is an apparent assumption – high business engagement (another pre-requisite) has to be complemented with the drive to learn the tool as a user and citizen developer. A good low-code no-code platform will do the rest. (Refer to PMI's Citizen Development Canvas to determine your company's level of maturity regarding the Citizen Development program). 

The promise of RME

Let us come back full circle to our Wheat & Chessboard problem. 

Staying ahead in an ecosystem of such astounding growth requires almost a sense of clairvoyance concerning user patterns and trajectories and an obsession with developing your product or app’s user base and product stickiness. The ability to measure and evolve RME can be a significant lever here, and the role that LCAP/NCAP platforms can play can be vital. 

The success stories with our customers have repeatedly demonstrated that product adoption can be fast-tracked by leveraging a low-code no-code platform. It ultimately helps teams to turn their enterprise application development upside down positively. 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Co-authored by: Srikant Radhakrishnan and Sharjeel Sohaib

You can reach out to Srikant at srikant.radhakrishnan@agilepoint.com or message him on LinkedIn.