So, you wanna start a lab?
Seven lessons from the field to help you prepare
As we encourage our clients to embrace a more responsive operating model that favors learning and shipping even over linear management and planning practices, the topic of building technology in-house often comes up. More and more we are recommending that you stop outsourcing the task — all this does is keep you dependent on someone else for updates, decision-making and talent, and usually costs a lot more in the long run.
One way to start owning your own technology and attracting the talent necessary to build best-in-class products (ones that compete with the startups who are invading your turf) is to start with a lab — one that can ship quickly and often, and that can begin forming the organization’s responsive muscle memory from the inside-out.
They have been called many things — intrapreneurship, startups within end-ups, labs, accelerators, squads, incubators, pods — and are defined differently by everybody, which can make the task of starting one daunting. This post is for those who have already decided to make the investment but may be unsure of what to expect; below are seven things to think about before before diving in.
Note: I’m approaching this topic of building a lab within a large organization from both a consultant’s and embedded product manager’s point of view, with the output being (1) digital products and (2) long-term organizational change.
1. A lab is not a shiny object.
Ok, let’s get this one out of the way. Many “labs” have popped up within big companies in the past few years, and the concept of having a small group of guerrilla makers can sound pretty exciting. But, if a lab is viewed (intentionally or not) from the start as a group that has nontraditional hours, does “whatever it wants” and comes up with big ideas all day long: it and its model is unlikely to be taken seriously or accepted as playing a crucial part in changing the organization. Starting a product lab within a big company is a massive undertaking that makes you a different kind of company and requires the commitment — from leadership first — to changing the way you operate both today on a small scale, and in the future at a corporate scale. If you launch and treat a lab as a PR Band-Aid, trouble is ahead.
2. Start with goals for both large and small.
Most multi-year business goals will feel unnatural to a small, agile team, but of course cannot be ignored. Make sure you bridge the goals of a philosophically and functionally agile group with the goals of the broader system. This is going to require constant communication between stakeholders and the refining of success metrics as you go — acknowledge that what one group considers successful won’t be clear or immediately important to the other. The key here is the ongoing management of these differences and early alignment. All of the lab’s work has to be in service of a broader corporate purpose, which will then bleed into measurement and reporting for each (more on metrics later). One way to do this is to revisit the product team’s goals semi-weekly and connect the dots on how each goal (or set of goals) ladders up to a broader corporate objective. For example, increased speed to market = early and frequent user feedback = more data points for Customer Insights.
3. Bring IT in early.
What do Marketing, Innovation and IT look like in your organization? How do they work together and communicate? Are there shared or interrelated goals? The tricky thing about digital product development is that the process and output spans all three of these disciplines. Traditionally, Marketing has had the deepest understanding of the customer, and Innovation has had an ear to the ground about what will be category-shifting in the future. These two superpowers today come together to produce digital products. Though, who has domain over a piece of technology in your organization once it’s built? Probably IT. In an ideal world, marketing, innovation and technology all come together to form a single powerful, user insights driven technology practice, but we still have a ways to go. It is imperative, if you are going to be building digital products, that IT is brought in early, as both a thought leader, champion and sponsor of the initiative. Your products want to see the light of day. ☺
4. Get comfortable with not knowing.
Embedding a small cross-functional team within your organization will involve rewiring your brain in the process department. A good primer for the philosophy of how your lab team thinks through problems and works best together is the 12 Principles of the Agile Manifesto. This one is about #2 — Welcome change, even late in development. Planning exactly what an experience will look like, under all use cases, takes up a lot of time that may end up being wasted in the end if the product is one that doesn’t solve a need or friction of your customers in the right way. Acknowledging that the work might pivot mid-course is imperative (and, when it happens, usually means we’re closer to building a successful product than we were before!). Becoming comfortable with the end result being a bit undefined will feel wrong or disorganized at first, but is important.
5. Start the osmosis early by embedding.
There will be cultural friction around the launch of a small cross-functional team of makers within your company, no matter what. It represents a completely different way of working that is far from what the rest of your organization is used to; some team members might resent the disruption of a new model brought in to evolve the DNA of the organization. This is a huge topic for a post on the cultural and psychological effects of organizational change, but the point is: try to embed the lab within the organization as early as possible, to avoid the physical signals of it being a separate entity that is set out to change everything for the crazier. The sooner the different structures and work styles are faced head-on and the full team is involved, the sooner the organ can start to catch and the two can co-exist while becoming more responsive together.
6. Give your team the authority to rigorously test.
One unfortunate byproduct of being a large organization is distance from the user. In the past, we have experimented with amending Kelly Johnson’s 14 Rules & Practices of Lockheed Martin’s Skunk Works. Number 9 was the most helpful: The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles. Our version of #9 looked like this:
The team is delegated the authority to rigorously test products in the field. We will solicit frequent testing and feedback (on hypotheses/final stage features, prototypes, rough builds, alpha versions of our MVP, etc.) from customers.
The thought of giving a small team the permission to test prototypes that haven’t gone through your company’s approval processes (or are off brand) can be terrifying, but it is critical for the lab team to get customer validation early. To me, this is all about learning from the people who will actually be using what you build. Customer research on a large scale involves heavily front-loaded work streams, its results coming in a very different format and schedule (waterfall & score based) than your product team will need (real time & context driven) for building at an earlier stage of maturity. The process of rapid prototyping and user testing yields a validated (or, better, invalidated) direction sooner.
The feedback you get from engaging directly with your earliest users will be the best you ever get. When you’re so big you have to resort to focus groups, you’ll wish you could go over to your users’ homes and offices and watch them use your stuff like you did when there were only a handful of them. — Paul Graham, Do Things That Don’t Scale
Aside: How this process works will depend on how heavily regulated your category is (financial services may require a little more up-front planning than if you are in food & beverage, e.g.), so keep that in mind.
7. Not all metrics are created equal.
What’s considered important to a large corporation isn’t necessarily shared or understood by a small team, and vice versa. Especially if you’re measuring the success of a completely new process and team structure than one that your corporate team is used to. For example, what mattered the most to me when our last product team was shipping a beta version of a customer service app were things like: (a) Average number of repeat completed transactions per user; (b) The speed at which we could update features to improve UX based on real time app usage; (c) Being able to tweak our backlog based on analytics & user data; (d) IRL guest feedback; etc.
Your corporation probably cares more about the bigger data that can lead to long term strategic planning — something like customer lifetime value (CLV) modeling, for example. I love CLV as much as the next person, but it isn’t useful when you have to apply it to how software is made, distributed and used as you’re making it. Incremental changes as you’re bringing something from MVP to a formal launch are far more complex than a single number, as they rely on not only the product team’s actions, but also on the immediately resulting user action (and sometimes other platforms as well — submitting to the iOS Store, e.g.). Point is, you will have to be constantly reevaluating success metrics and engaging in two-way stakeholder management accordingly. Recognizing early that you will have to reconcile what will make the product team happy and contribute to their success and what your organization needs to measure for its long term goals will prevent friction in the long term.
To learn more about Responsive Organizations, visit undercurrent.com and stay up to date with our latest thinking by subscribing to our weekly newsletter.
