Sign Up

Subscribe! It's free.

Join >690 folks who use these tools and ideas (everything here requires registration; it’s your call if you want a newsletter about it).

Subscribe
By Clay Parker Jones profile image Clay Parker Jones
3 min read

21 Rules for Lab Development

Innovation Labs need rules. Here are 21 that I documented in 2014 during my work inside and alongside four different such labs. They work!

  1. Start small. Everyone should agree at the outset to limit the scope of what the lab aims to do. Groups seldom follow this advice; there seems to be a natural desire to add features and commentary, even when they’re unsolicited.
  2. Be okay with the duct-taped solution. Someday you may need an enterprise email solution, but today, just use Mailchimp.
  3. Ship early and often. This is an easy one to preach, and to rally behind, but many labs fail to follow through. What constitutes “shipping”? Engineers will argue that refactored code and server enhancements count, and they’re right. But the most important thing for the success of the lab is to have working stuff in the hands of users.
  4. Make hard decisions as a team (regarding design, functionality, etc.), but let the user’s voice speak loudest. If they don’t give you great feedback on a feature, kill it. If they don’t use your product, pivot. And when we refer to a “user”, that can be an internal audience, too.
  5. Before actually building a lab, come to a highly specific and mutually agreed understanding of what is broken in the organization. Is it the culture of work? Is it the output? Is it a customer experience? Come back to this constantly.
  6. Determine the single metric by which the lab will be judged. Stick to it. Develop foolproof ways of measuring it. As best you can, tie compensation of lab participants to their success against their metric.
  7. Create a dedicated, protected budget for the lab, and do not ask the lab for breakouts of their costs. Instead, judge them by the metric described above. Carry this learning to other digital efforts by defining goal-based budgets, rather than line-item budgets (which encourage the maintenance of status quo).
  8. Aside from compensation, do what you can to connect participation in the lab to individual glory, promotion, and/or fame. In highly hierarchical environments with immobile compensation models, getting a seat at a key internal meeting (as a result of lab success) can be a huge motivator.
  9. When determining who will be in the lab, look first for a charismatic, fearless, knowledgeable leader. They must be able to get up-and-down buy-in about/within the lab, and must be an effective politician. This does not need to be a digital leader, but if they’re not born-digital, they must be willing to learn.
  10. The lab should be a priority for the C-suite.
  11. C-suite leaders must be disciplined: they must fight for the autonomy of the lab, but resist the allure to roll up their sleeves and work inside the lab. Note: as the lab gains momentum, this allure will grow stronger.
  12. Project liaisons for the lab must not require frequent reports of lab activity. However, the lab should maintain comprehensive documentation of its efforts.
  13. Assess and understand the level of risk associated with the work of the lab. Might you infringe? Might you fail to protect customer data? The answer to both of these, unfortunately, is a likely yes. Most people will demonstrate a high appetite for risk at the outset of a lab project. This appetite tends to decrease over time, and early recognition & accounting for risk is important.
  14. Consider building for internal audiences first. Risk escalates when the output is customer-facing or public in some way.
  15. Decide how much impact you wish to achieve with the formation of the lab, and weigh that against the risk associated with the effort. In general, labs will accept risk in trade for organizational impact. Due to their typically in-house nature (which ensures that the lab owner captures the benefits associated with intellectual property and group learning), risk will likely come direct to the organization rather than through a third party.
  16. If enough upside is available through creating a lab, do what you can to bring the lab in-house. This will require a significant amount of legwork and persuasion; adding new headcount is always an issue. With that said, it’s essential to bring the company (through the lab) as close as possible to the customers, and the ongoing skill-building within the lab isn’t something you want to give away to another organization.
  17. Get the team working together as soon as possible. If you’re bringing in new resources from the outside, have them do homework together to test their collective skills and inherent project management capability.
  18. Labs accelerate over time. Their pace improves, and the impact they have “tips up” rapidly after slow initial growth. As such, at the beginning of the effort, it can feel as if nothing is working, or that no progress is being made. Resist the urge to intercede.
  19. Plan for the end of the lab effort. How will their outputs scale? What is their “time to proof?” How will their focus change after they prove success? How will the lab grow without becoming bureaucratic?
  20. Allow the lab some measure of isolation from the day-to-day operations of the company, and aim to physically locate their workspace as close to customers as possible.
  21. Legacy systems and existing plans should be avoided at all costs.
By Clay Parker Jones profile image Clay Parker Jones
Updated on
Innovation

Read Next