Secrets of an Agile Incubation Team
By: Dan Platt
One of my favorite parts of my job at Narrative Science is working as the Product Manager for our Incubator program. The mission of our Incubator Team is to leverage customer and market insights, and the latest innovation techniques, in a rapid prototype environment to quickly develop and test new capabilities in order to ensure that Narrative Science remains the undisputed leader in the advanced NLG market.
Our small team of, at most, three people, has helped influence our way of thinking, our roadmap, and the vision for the company; as well as, the types of values we can ultimately provide our users.
For anyone thinking of spinning up a team like this, I think there are a few secrets to making the initiative successful. Another blog post described strategic ingredients for success as, “support of the C-suite, having the right operational model, and the right people”. Instead, as someone involved in the day-to-day, I want to give more tactical specifics on how to drive performance and demonstrate value.
First, keep your eye on the prize and don’t allow yourself to be distracted by “shiny objects” along the way. For instance, there may be brand new technology that you have been tempted to experiment with but ultimately the project would reap a short-term reward and not benefit the company in the long run. You will find many moments along the course of an incubation project where you could lose focus. Incubation projects are more open-ended than the features you are building for your mainline products but you have to concentrate on exactly what the underlying ‘point’ of the project is. What capability are you trying to prove? At Narrative Science, our projects last around two months. That is not a lot of time to build something completely from scratch. You have to always have your eyes open for inspiration that will cause you to spin your wheels for days or weeks. A week of lost time in a two-month project is significant.
Second, if you think of these projects as building a ‘mini product’ instead of some academic exercise, you can embrace the idea of delivering a ‘Minimum Viable Product’ or MVP. The definition of MVP is “a product with just enough features to satisfy early customers, and to provide feedback for future product development”. How do you do this? We have adopted the methodology of getting to a basic end-to-end demonstration as quickly as possible and then building from there. When we get started, we ask ourselves ‘What is the minimum set of features we need in order to show this basically working end to end?’ Once we’ve built that, we maintain maximum flexibility to prioritize future work.
Throughout the process, the question my team and I reflect on is ‘If the project abruptly ended after we did X, do we think we could show what we have and our audience would understand what we were trying to prove?’ If the answer is ‘yes’, then that is our MVP.
Third, if you think of your projects as actual products, you can adopt an agile methodology and be willing to embrace change more easily. Understand that the demonstration you may have had in your head at the beginning, may not be what you end up showing at the end. There may be problems that would take too much time to solve or you may realize that once you’ve put shovel-to-ground on the project there were capabilities unearthed by accident. You have to be willing to pivot and adapt. If you have regular check-ins and problem-solving sessions, you can identify these pivot points and change course.
Lastly, and related to all of the above, focus on the value you are trying to deliver. In an incubation setting, it can be easy to look to solve problems with emerging methods or use new technologies you want to experiment with. For us, many of our incubation projects are related to Artificial Intelligence (A.I.) or Natural Language Processing (NLP) and Natural Language Understanding (NLU) to go along with Natural Language Generation (NLG). This presents many opportunities to get very experimental with our approaches. However, if you can prove your concept via “tried and true” approaches, there is nothing wrong with that. You are trying to tell a story about where your product could go, not how you can leverage some new or emerging technology.
The analogy we use is that you don’t need a giant mallet to hammer a small nail. Keep a laser focus on the value you ultimately want to deliver to the user and how you can effectively demonstrate the value this incubator project will provide. If through the course of your project you need to use a small hammer to hammer a small nail, that’s ok. You are trying to demonstrate that you can build something tangible, not that you can handle a giant mallet.