The 6Ds in Research & Development


When it comes to building new products or selecting technologies for the job, we usually start by doing some type of research. Some read a book or an article, talk to analysts, buy a few reports from Forrester or Gartner, and make a decision right away. But not everyone can derive and make practical decisions from reading materials that are usually written for ideal situations. And some would avoid doing any type of “research” because they believe research in their field means generalizing a list of analyst reports without practical hands-on testing. They would rather be reactive and purchase from one of the biggest brands. And some would simply stop everyone else in the organization moving forward and say “we can’t proceed without all clear requirements?!” (Though, inexperience plays a role in the last example.)

Among all the industries, pharmaceutical companies and high-tech research organizations have well defined R&D processes in place that ensure quality control and safety because a small mistake can lead to catastrophic disasters. Those processes, however, are not necessarily as agile nor fast-paced for most software product development lifecycle. So here is a research & development process that is both repeatable and agile. Variations of this can be adopted into your existing waterfall and SCRUM-like processes.

Discovery, Design, Development, Demonstration, Decision, and Debrief.

1. Discovery and Research

The discovery and research phase is basically for you to discover possibilities around potential use cases, types of users, list of relevant market products, potential competitors, technology trends, gather market statistics, interview potential consumers of an idea etc. In some organization, this is where “ideation” happens. So after spending time to understand the market, based on information discovered you may theorize around potential approach or solutions. But nothing is off the table as it is still at a very early stage. Note that if you jump to the next phase too early, in practice, you may end up spinning and spending a lot more time overall. So use your best judgement when the time is right!

Key output: A list of relevant tech products, comparison, ranking, key thoughts

2. Design and User Story

When you have gathered enough information from the discovery phase, you can start transforming your list of ideas into user stories and sketches. In the agile world, this is where EPICs are being defined; in the waterfall world, this is where business needs and business requirements are being documented. And for enterprise architects, this is when you start mapping new user stories into the overall Business Capability Map.

Analysis paralysis is something that you definitely want to avoid in this phase. If there is a key piece of information missed from discovery phase, which happens a lot in larger projects, you can quickly include new information as you develop or refine user stories. But do not stop the process nor momentum for every minor details. Making educated assumptions may sometime make sense. With valid reasons, such as miss identified a segment of customers or early product pivot, you may want to reset the process back to discovery.

When you have good enough inventory of user stories, you should consider prioritizing user stories and define a reasonable scope. Depends on your organization structure, utilize the most productive method to prioritize scope. But keep the committee small and agile, and don’t forget the inputs you received from customer interviews during discovery.

Key output: Prioritized user stories and high level proof of concepts

3. Development and Testing

Once you have a defined scope for your MVP or a phased project, you can translate user stories or sketches into wireframes and prototypes. Depends on the type of technologies, rapid prototyping or proof-of-concept may be needed for better decision making. Always take the hands-on approach as you select the right framework or platform to fill the needs. Spend the effort to test drive technologies and always think of them as investments. And to balance your time spend evaluating short and long term technologies.

If you are bootstrapping a MVP, you definitely want to do this with “Fail Fast, Fail Early” in mind. So you can redefine your product and try again. Check out Steve Blank’s The Startup Owner’s Manual and Eric Ries’s The Lean Startup for further guidance.

If you are buying a new technology, make sure you test with business use cases relevant to the needs. Some methods in enterprise architecture practices may be helpful to you as well. The actual development and testing can be done through waterfall and agile methods; use your best judgement to manage the development and testing cycles.

Key output: Detail proof-of-concepts and results

4. Demonstration and Presentation

This step is mainly to focus on your organization and how decisions are being made and communicated. If you are bootstrapping a MVP, you may need to demonstrate the new product to potential customers, VCs, or board of directors. If you have created enhancement to existing applications, this is basically your final UAT before production launch. And if you are an enterprise or portfolio architect, this is when you present the prototype / proof-of-concept, technical findings, technology roadmap and strategic investment plan for the next 2–3 years.

Key output: Collect feedback on recommendation, incorporate recommendation into future plan

5. Decision and Contract

This phase is the most exciting and boring part of the process. Obviously, if you are buying a new technology to support your business, you may be entering a months-long contract negotiation. And if you have built a new product you may be working to get additional investors.

Key output: Final Decision and signed contract

6. Debrief and Transfer

For large organization, this phase is usually needed to transfer knowledge and responsibilities to proper owner of the new software or platform. This step is not necessary for startup or medium-sized DevOp teams. Sharing lessons learned from previous phases is generally a good idea for the team from management standpoint. For enterprise architects, this is the activity part of the transition stage, and lead to governance creation.

Key output: None

Above is a R&D process which can be adopted by both transitional waterfall and newer agile organizations. Regardless of new product development, enhancing existing platform or small buy-before-build project, this can be easily adopted.

I look forward to your feedback, and happy holidays!

This article was also published on LinkedIn.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.