Part 3: P(Q)RS Methodology for Competitive Advantage

Introduction

P(Q)RS or aka P2R Agile Methodology is a comprehensive Agile framework.

Let’s Start with the P Phase (low-cost low risk pre-scale phase)

Product Proposal

A product is an object, or system, or a service for a customer.

Product Proposal may initiate as a business case, Business Model Canvas or a Value Proposition Canvas for a B2C or as Business Intelligence (BI) request from a Business Leader to access business insights.

For B2C, product invention or product differentiation creates a competitive advantage as the market landscape changes. Product innovation may become a necessity, and longer Time To Market (TTM) can be detrimental.

On the other hand, Business Intelligence brings a potential competitive advantage by supporting fast data-driven decision making to keep the business agile. Strategic corporate planning demands unstructured decisions [Decision Support System (DSS) – by Gorry and Scott Morton decision framework]. Inherently, specifics of the problems trying to explore & solve, or specifics of the opportunities pursued, cannot be described in detail due to novelty & lack of knowledge. Thus, BI questions and expectations are changing in order to make fast objective decisions.

These solution developments require an adaptive approach.

Pilot project

Product development essentially requires strategic planning, Analysis & Design, Finance, Legal & Risk evaluation, Testing & Development and Marketing. Hence, Pilot project comprises different roles or tasks to perform - which translates into a cross functional team.

Carefully constructing the incubator team (or the start-up team) with the right mix of skills can increase the chance of success.

However, the phrase “culture eats strategy for breakfast” [father of management thinking, Peter Drucker] still applies. Team culture is created primarily by the actions of its leaders. A leader should:

• Exhibit core values to instil them among team members
• Inspire the team to “reach for the stars” so at least they will land on the moon
• Foster psychological safety for even if the team did not land on the moon at least they “feel safe that they are on earth and not in hell”
• Have resilient leadership: knowing that absorbing uncertainty & tolerating failure is a necessary aspect of the innovation process
• Reframe unsuccessful attempts as learning experiences to encourage the team to take challenges
• Celebrate achievements! Retrospect objectively - focusing on “what is right instead of who is right”
• Cultivate team cohesion and encourage colleagues to surround themselves with individuals who complement their strengths
• Balance the project progress with the well-being of the team

Product Properties/Features

Have a deeper understanding of the customers. Identify the product properties or features that will serve the Needs, Wants & Inconveniences of the target audience.

Identify Product properties that will be:

• Useful (addresses customer needs, functional and creates value)
• Usable (tackles customer inconveniences, rapid & reliable)
• Desirable (caters to customer sentiment & brings satisfaction)

Presumed Minimum Viable Product

Product features for the soft launch should be carefully selected. Identifying a Minimum Viable Product (MVP) is an exercise on its own. To do so, one must determine:

• What is minimum? (Identify the main purpose of the product)
• What is Viable? (Presume the valuable product features from a customer’s point of view to easily communicate & capture customers’ attention)

Product positioning will depend on the target audience. Marketing research may produce an understanding of customer needs and motivations.

Prioritise Product Properties: Presume and prioritise core product features that will benefit the target market in order to gather & determine initial customer feedback from the segment of the target audience.

If the product is a service, think of the most efficient workflow that will convey value to the customer as the initial MVP.

Proof of Concept (Feasibility)

Feasibility of the Presumed Minimum Viable Product should be examined from a technical, economic and compliance point of view (and optionally operational feasibility) before further investing on the Product build. Proceeding without considering these risk factors can hinder progress.

To test product feasibility:

• Experiment how the product can be integrated in the current landscape (is the new product is compatible with current devices? Explore other usages of the product)
• Estimate if the product is financially viable with the current funding – will it “Run out steam without $upply”?
• Consider conformity to national (and international) statutory and regulatory obligations
• Study operational feasibility well ahead (allowing one to be well-placed to scale) - check that resources, skills, competencies, and work processes are scalable for a demand surge

Note: Scheduling feasibility was purposely left out – is it possible to guesstimate a nominal timeframe for something that has never been done before? Innovation is non-linear by nature, it involves cycle of learning, trial and error may require 'n' number of iterations, and ‘n’ cannot be accurately predicted.

Prototyping

Proto is defined as ‘original’ and typus as ‘model’ – at least in Latin!

Design, build, experiment and explore to refine the MVP Product concepts, assumptions or processes. ?

Prototyping can range from graphical and physical to digital interactive - or a simple storyboard to encapsulate the customer workflow/sequence.

Verify the prototype (Alpha Testing) to help sort out several bugs, technical glitches, design issues and UI/UX issues before going into the MVP validation phase (Beta Testing) where users are involved. Testing the prototype(s) will appeal for significant changes based on the results and feedback, and so improve the model from what is learned - rework is the norm!

Papyrus

‘Papyrus’ significantly contributed to human advancement by allowing to keep account of records and preserving lessons learned.

Maintaining a knowledge base for the project will help avoid repeating the same mistakes made during the product development, help to analyse and improve quality, plus work as future reference to understand ‘why we did what we did’. Thus, the term ‘Papyrus’ is included in the methodology to emphasise the importance of documentation.

Creating quality documentation is relatively expensive considering the extra effort entailed, just as creating quality papyrus was relatively expensive. However, the return on investment (ROI) in quality documentation is high, and is imperative for product success.

Prove MVP

It is difficult to tell in advance which ideas will be the most profitable. Beta testing is ‘when the rubber hits the road’. Using the 6 P's of marketing (product, price, place, promotion, people, and passion) one will be able to:

• verify the need for the product or service in the marketplace
• clarify the presumptions. CHECK the hypothesis of the presumed MVP

It is also important to test MVP in order to determine the:

• market demand from the target audience/user
• marketing channel effectiveness
• target outcome centric (e.g. product profitability)

3P is a phase-gate

Pivot, Persevere or Patch?

Testing MVP via a segment of the target audience is a turning point, it provides three insightful options:

1. Persevere the realistic product to scale (‘demand-driven growth’)
2. Patch the MVP with a different set of product properties and goes into prototyping cycle as hypothesis about Presumed Minimum Viable Product is incorrect
3. Pivot the initiative if it’s very unlikely to meet strategic target outcome

Q is a State rather than a Phase!

Quit

'Never give up; never surrender!' A catchphrase from the movie Galaxy Quest. There is stigma around quitting, as “never give up” promotes motivation and perseverance.

However, at times it is quite essential to ‘cut your losses short’ as a risk management strategy, to prevent a Pilot project from turning into a White Elephant Project. The ‘fail fast’ mindset will prevent the project from falling too steep to recover, both financially and mentally.

P(Q)RP Methodology provides two occasions to quit:

1. When the proof of concept proves product development as not feasible (either technically, economically, legally and/or operationally)
2. When testing the MVP proved that new product is very unlikely to meet strategic target outcome

R Phase (product Refinement)

Refine Realistic Product

When MVP is tested on the Market segment, is a demand driven growth visible? Real need due to demand will approve MVP into detailed Product Development.

“Prove MVP” (MVP validation) stage will also provide insight into features that can be improved, added, or omitted - continuously analyse and test the Product, package the MVP with features & perfect the Product.

Thorough testing of Product’s functionality, usability, reliability, performance, and security ++ quality attributes (functional and non-functional requirements) should be performed before scaling.

FURPS+ model developed at Hewlett-Packard indicates to test:

• Functionality - Capability (Size & Generality of Feature Set), Accuracy (Frequency/Severity of Error)
• Usability (UX) - Human Factors, Aesthetics, Consistency, Documentation
• Reliability - Failure Frequency (Robustness/Durability/Resilience), Recoverability, Availability
• Reusability - Compatibility, Interoperability, Portability
• Performance - Speed, Efficiency, Resource Consumption (power, ram, cache, etc.), Throughput, Capacity, Responsiveness
• Security & Safety
• Supportability - Serviceability, Maintainability, Sustainability, Scalability

And then we are ready to scale! ??

Let’s continue with the S Phase

Scale the Product

Scaling from a Pilot project to the next phase call for careful consideration.

Incubator team’s (or the start-up team) composition & competence needs reconsideration.

Encourage proactive training for the existing team to take greater responsibilities and master new skills when scaling.

Place new team structures, processes and communication channels for the expanding team to fit the next project phase.

Prioritization and planning to synchronize different team + Suitable scalable Architecture in place for smooth deployment and integration.

Absence of clear documentation in place for the new comers to refer intensifies with the lack of availability from the founding team.

Constantly contemplate improving the product for greater customer satisfaction. After all Software Development Life Cycle (SDLC) is a life cycle.

"Are you ready?" to leap and lead with the P(Q)RS Product Development Methodology?