A Quick Guide to Nanoprojects: A Lean Method for Product Design

Authored by: Matt Grasser
November 29, 2017 - 6 mins read
Image Credit: Tech in Asia

At BFA, we have been working on an R&D program called FIBR. We partner with local businesses in Ghana and Tanzania to explore the potential for burgeoning technologies, such as smartphones and machine learning, which are increasingly available in these markets, to create opportunities to expand access to financial services. A major component of this program is to quickly assess the fit of a potential partner/product/solution for a relatively lengthy engagement.

Nanoproject Motivation: “Doing” beats “Planning”

While one seemingly attractive approach to partner selection is to meticulously design an airtight system at the outset, we have found that the best means to understand a system is by replacing a large portion of this planning with actively doing.

“In theory, there is no difference between practice and theory. In practice, there is.” –Jan van de Snepscheut

This approach is particularly useful in areas of high uncertainty where FIBR partners typically operate. It is with this spirit that we realized this concept of “learning through experiments”, designing a small set of preliminary, targeted engagements with concrete deliverables, which we refer to as a nanoprojects.

Nanoprojects share a common goal with the Design Sprint: to take the shortest path from an idea to the subsequent learnings. (Image Credit: Google Ventures)

The nanoproject approach, described below in detail, has proven useful in selecting partners and de-risking collaborative product development across a wide variety of FIBR partnerships. Here are a few examples:



The nanoproject approach has proven useful in selecting partners to collaboratively design and deploy a wide variety of financial technology, products, and services. (Image Credit: Tech in Asia)



What is a Nanoproject?


In short, a nanoproject is an exercise in shortcutting the often-slow process of uncovering and understanding the risks inherent in a partner, product, and/or service.


Nanoprojects seek to take the shortest path from an idea to the learnings generated through pilots and trials. Having these lessons in hand earlier and faster means the organization is exposed to less risk when introducing new products or services. In particular, nanoprojects seek to lower:

(Note: the preceding list is not intended to be comprehensive, but to illustrate a key set of considerations in selecting a partner)

Rather than just assessing these risks on paper, the nanoproject is a 1-to-2-week engagement that tests some of the key risks in practice. This approach enables a thorough analysis of at least the most critical areas of uncertainty before moving into a fuller, months-long engagement.

“Risk comes from not knowing what you’re doing.”
–Warren Buffet 


Walking the product design “tightrope” will inevitably involve risks, but with the proper team, tools, training, and preparation as part of the nanoproject, these risks can often be largely mitigated.


Nanoprojects Step-by-Step

In a nanoproject, we work with the partner to define mutual goals, select an approach that tests the feasibility of these goals and whether our hypotheses/assumptions are reasonable, and finally put it all together in a formal document that we deliver to the stakeholders.


Step 1. Defining Goals.

The first step is to pick out the highest risk areas, hypotheses, assumptions, and explore them just enough to begin to understand the risks and mitigation strategies. This is typically done via a web conference or, ideally, an in-person workshop, lasting approximately two hours. This artificially imposed time constraint forces the participants to focus on critical areas of co-scoping, and limits the introduction of “yak shaving” problems, in which a particular technology specification overshadows the core real-world goals of the engagement.


Step 2. Selecting a Testing Approach.

Depending on the goals identified in Step 1, one or more of the following methods may be deployed to test feasibility.



Day 1, Share. Select a team that maximizes the depth and diversity of the expertise and experience in the room (e.g. experts on context, user experience, tech implementation, business modeling, data, etc.) to describe the ecosystem surrounding the product or service in question and identify pain points in the process. End the day by selecting one pain point to focus on.


Day 2, Diverge. Each participant should spend time individually drawing a 3-step l solution to the problem identified on day 1. (protip: using thick markers on index cards helps to keep this process focused on the major features and less on the details of UI) Next, each participant should then briefly present a description of their solution, and post their sketches on a wall. Finally, each participant is given an equal number of stickers to identify their favorite features from everyone’s ideas.


Day 3, Converge. As a group, review the solutions from the previous day and take note of the most sticker-adorned features. Use these features to generate testable hypotheses (e.g. “implementing a text-to-speech feature will encourage less literate customers to better understand the terms and conditions”) and come to a consensus on which 3–5 features you’ll test.


Day 4, Prototype. The goal for this day is to do the least amount of work required to test a hypothesis. This may mean building a paper prototype, a rough-around-the-edges mobile app, or something in between like a Google Form or an AppSheet app; whatever is the shortest path to getting answers to your hypotheses.


Day 5, Test. Get out and visit the prospective users of the product or service and let them provide you with the answers to your questions, implications of your assumptions, and validation of your hypotheses. Repeat from step 1 as necessary.


Step 3. Producing Deliverables

Each of the testing approaches above can lead to a unique type of output, but each approach should accomplish the high-level goal of removing risk from the project. For example:


With these outputs in hand, the team can decide whether (and how) to proceed with the product or service in question.



Members of the FIBR team who were involved in the aforementioned educational fee savings program, at the completion of the Design Sprint nanoproject based out of IT Consortium’s offices in Accra, Ghana. A draft of the Lean FIBR Canvas deliverable for this engagement can be seen here on the whiteboard behind the nano’s participants.



Limitations to the Nanoproject Approach

Realistically, there is no way that 1–2 weeks of work can fully mirror a larger pilot test. That said, through this small up-front investment, the expected value of the overall project is higher; an unsuccessful nanoproject is cheap, and success can provide critical validation around the most volatile and riskiest parts of the ventures.



Nanoprojects are a small investment with a huge payoff. They are a cost-minimizing way to give us the nudge we need to stay on the right path, or tell us quickly that no safe path exists to lead us where we’re trying to be.


“The journey of a thousand miles begins with one step.”
— Lao Tzu 



Related Publications
Leave a Reply