Scaling and growing your innovation lab’s project
In the world of systems change, the launch of your public innovation lab’s product, project, or programme (we will use the generic term ‘product’ throughout this column) does not mark the end. Rather, the launch - which enables you to assess how real users interact with your product - brings you one step closer to identifying a solution for the issue you want to address at scale.
The Nesta report, Making it Big: Strategies for Scaling Social Innovations, features a definition of scaling that’s helpful when thinking of scaling your lab project too: 'Social innovations can be said to have scaled when their impact grows to match the level of need.'
Finding a solution that can demonstrably address a problem in a particular context is one thing. Yet finding solutions that can address multi-causal manifestations of the problem elsewhere quite another. In this month’s Tech4Labs we will introduce you to some tech tools and tips to help you as you consider possible routes to scale for your lab product.
Failing and learning fast
As mentioned in our previous column, you should have defined some clear metrics to measure how effective your product is at meeting this need. Admittedly, this will be a lot trickier with particularly complex, “wicked” challenges. Being clear from the outset on some of the shorter term impacts you’d hope to see, and iterating and testing your lab product for them should occur before you start to think about scaling and growing your product. (See here for a nice example of how FutureGov evaluate as part of its product development process).
If the evidence is not there, consider making a few changes (referring back to your ‘pre-mortem’ and wherever possible gaining user insight). In certain scenarios it may be appropriate to shut down your product (product people prefer to use the more poetic term"sunset"), gathering the key lessons before moving on your next experiment.
If you do have to "sunset" a product, make sure you do it properly [8–10]. This is especially important in the context of public services, which impact key elements of the lives of real people. Tell your users why you are ending the service. Offer them an alternative or a substitute if needed, and where relevant and possible, let them export their personal data in a portable format.
Communicate both internally and externally, sharing the learnings from any failings and iterations along the way. (This short paper from InWithForward – a PSILab based in Canada – on the Burnaby Startup Project demonstrates how this process of learning through iteration is central to its lab process. Equally, Bromford Lab has communicated the importance of failure as a driver of the lab’s learning).
'I have not failed. I've just found 10,000 ways that won't work.' ― Thomas A. Edison
Getting your scaling strategy right
The lab process is by its nature highly collaborative. Working with stakeholders should help you consider the best route to scale, leveraging both your direct team’s and your partners’ skills, knowledge and connections. There are a number of pathways to scale, many of which have been laid out in Making it Big. Consider which best fits your scaling goals, the barriers to scale (be it policy, regulation, or demand) or if scaling is appropriate at all.
Just because your lab product has passed initial evaluations does not guarantee it will work in new contexts, or in other sections of the population. The same commitment to experimentation and testing should be followed by others deploying your idea. Ultimately, your product should never sacrifice impact in the pursuit of scaling.
Below we set out some useful tools and tips to help with the deployment your lab product, and offer a few ways for you to consider growing your user base:
Deploying software solutions
If your pilot lab product is software based, it’s highly probable that you’ll have launched your product as a limited pilot in a pre-defined geographic area or for a selected population, hopefully following some of our pretotyping advice (see our past column). In the previous columns, we introduced you to the concept of pretotyping to help you ensure you’re building the right 'it'. Your deployment will be easier if you made the right technology choices early on. For software products (e.g. website, mobile app), enforcing and removing such restrictions is easy. Cloud-based services are easier and cheaper to scale up. While responsive applications make it trivial to expand to a wider range of platforms (mobile, laptop, desktop, TV).
Scaling online services
Online services can be targeted using the user's IP address that gets mapped to a location (online advertisements use this technique all the time). This is like the infamous region code for DVDs, but applied to content and services, aka geo blocking.
Mobile apps can be restricted at the country level when you publish them in an app store. This could be relevant for an EU funded project where you start a pilot in country X before you expand to the rest of Europe. Mobile apps can also use the user's location (via GPS) to ‘trigger’ - meaning the app will only be available to use in the designated area. This is called geo-fencing .
Simplifying your software product
If you plan on having external teams (outside of your lab) deploy your product, make sure it is packaged properly. First make sure the code is open source (e.g. on GitHub) to encourage others to use it. Assuming that this will be enough to encourage others to reuse your code is a mistake however. You can make your code more reusable by making sure your product is properly documented and installation is straightforward. A technology like Docker is a very easy way to make a software installation a one-click experience.
Scaling in-person solutions
Where your product is not a software, it’s still advisable to have good documentation. Create a playbook for people who want to deploy your product (Bloomberg Philanthropies, for instance, has created a useful playbook on its Innovation Delivery Model which has been used to tackle some of the thorniest challenges faced by mayors in the US). It is usually a good idea to create a community around the product where people deploying it (for themselves or on your behalf) can share tips and exchange best practices. A mailing list or a web forum (such as Discourse) can be a good starting point, and you may want to host a series of webinars around key aspects of implementation using a web conferencing platform like GoToMeeting.
The franchising model
A good way to think about this way of growing is the franchise model. You want other people to replicate the success of your pilot. You need to make it easy for them to get some help, exchange tips, etc. But you also want to guarantee quality and integrity of the product is maintained. Make sure you find ways to keep track of how these deployments happen. For software products, ensure logging and reporting are baked in. For non-software products, encourage "labs franchisees" to share their results.
Reaching more users
Depending on the nature of your launch (see previous column), getting more users might mean different things. In certain cases you may want to consider traditional marketing techniques to raise awareness of your product amongst potential users.
Try online ads
Online ads (based on search queries such as Google AdWords or based on content in the manner of Google AdSense) are easy to set up, and don’t require a big upfront cost. You can start with a $5 budget, but it does not mean they are cheap in the long run. They provide lots of targeting capabilities such as geography, demographics, devices, etc. This may be a good place to start if you are focusing on a population that you don't have much information about.
Leverage mailing lists
If you already have contact with your users (they are already using your product, or have registered as part of a prior programme), mailing lists are a good option. Tools like Mailchimp and alternatives make it very easy to send mass emails. They also make it easy to experiment and figure out which messaging works best. A few things to consider with such services: price, personalisation, tracking of response, analytics. Bear in mind that modern email clients can detect such mass communication and mark it as spam. It is sometimes better to use your personal email address and instead make the communication appear more personalised using tools like Thunderbird MailMerge, and Outlook MailMerge.
Don't exclude traditional ads
Traditional ads such as subway ads, newspaper paper ads, radio ads or even TV ads are more expensive to produce and run and take longer time. But depending on your target population, they might work best.
Bringing your message to new users is hard. Consider bundling your message with someone else’s product or service. Also, don't be afraid to reuse traditional guerilla marketing tactics . At the latest open data conference in Ottawa, GovLab used the opportunity to promote some of its services. Creating some simple business-card-sized flyers, and pieces of schwag (lens cloths) to give to attendees meant a number of its "products" were promoted.
GovLab business cards, mini-cards and branded lens cloth. Image courtesy of GovLab.
The idea of viral marketing [12, 13] is to let the "message" (about your product) spread like a virus. Using word of mouth and its extension through social media, people spread your message to their friends and convert them into potential users.
The best viral marketing (see [3, 11]) works by itself: people share because they find the message interesting. Sometimes, there needs to be some incentives or nudges (As with the quid pro quo launch approach outlined in our last column).
Building a community around your product is also a good way to get more users.
Public forums like Discourse or wikis (e.g. MediaWiki, powering Wikipedia, or others) are good tools for that purpose. GovLab recently helped build the NetMundial Solutions Map, an online tool "to support information sharing and collaboration across Internet governance issues". A key element was to make the tool open to the public for contributions with a list of contributors and a dashboard. This creates richer content, and encourages people to share and tell their friends about the tool.
Scaling in the public sector is known to be challenging, and will likely require something more than evidence and good documentation. Being as open as possible with your idea (open source, open data and open publishing) and telling the story of the impact it’s creating so far (through quantitative data and user testimonies) will help others see the value in it, and build demand (whether that’s amongst commissioners, policymakers, or other potential ‘willing adopters’).
Volvo famously gave away its greatest invention – the three point safety belt – because it was too significant not to share. At the 50th anniversary of the invention, it was estimated to have saved over a million lives. Food for thought if you find yourself considering the scale of ambition (and impact) of your lab product.
To continue the conversation, and to offer feedback and suggestions on the tools above:
share your comments below
or on Twitter using #Tech4Labs