About 9 of every 10 of your business ideas are going to fail. Would you try to reduce this percentage, or instead try to invalidate the non-viable ones and move on with THE great game changer idea? In order to convince you to do the latter, we interviewed the writer and business model innovation consultant Sam McAfee. After being part of dozens of failures, a handful of successes, and working for companies such as Adobe, Sharethrough, Teach for America, and PG&E, Sam shared with us the key concepts and takeaways that will help you to take your business to the next level.
Could you share any success or failure cases where companies applied an agile MVP methodology to develop new products or services?
The experiment-driven iterative approach methodology we developed at Neo, I think, is one of the most rigorous approaches to new product development around. Neo is no more, alas, but a lot of us still use the approach we developed there. We’d go from an idea on a whiteboard to a working MVP in 12 weeks, using a combination of Design Thinking, Lean Startup, and Agile methodologies. We must have done dozens of these types of projects for Macy’s, Time Inc, Toyota, and others.
One in particular stands out for me. We built a social marketing application for Adobe, that was code named “Spruce”. The Neo team was able to iterate through customer interviews, landing page experiments, and prototypes, all the way to a working system in 12 weeks. In that project we were able to validate and invalidate a set of assumptions that our clients had about what marketers wanted in a tool. It was so successful, we were turning away calls from investors who thought it was a real startup. The output from that project was the inspiration (at least in part) for what is now known as Adobe Spark. That’s a really good example of the power of this MVP model.
We certainly saw some failures as well. But keep in mind that these were failed ideas, not teams. Invalidating a bad idea is actually a successful outcome from the point of view of an experiment-minded entrepreneur. About 9 of every 10 of your ideas are going to fail. And I think nothing could be more efficient than quickly and cheaply invalidating the 9 bad ones with a process like a 12-week MVP. Often we were able to kill ideas way before we got to week 12. That’s considered a win because you’re saving the client money and time.
After working in several companies for numerous years and having now the opportunity to asses them “from the outside”, which advice would you give to someone who is leading an innovation project in an already established company?
There are a few key things I’ve learned that would impart to any innovation leader. First, make sure you organize your people into small dedicated, cross-functional teams. Innovation is hard, and no-one does a good job if they are split across different projects or dealing with hand-offs between functional silos. Too often, we find IT over here, product management--or worse, project management--over there, and design somewhere else. That’s a recipe for disaster with regular delivery teams, much less for anything that has to move at the speed of startups.
A second key thing is make sure you have “air cover” from the executive team. What happens a lot is that you have an innovation project underway, and then there is some kind of emergency, or re-prioritization and you have to give up some of your team to deal with it. You need to have executive support that prevents this kind of thing from happening.
Most importantly though, is to find some way to work on projects in a portfolio manner, having different teams running different experiments in parallel. Most of your experiments will fail, so you just have to get used to that idea, and build your budgeting to support it.
Which are the 3 do’s and don’ts to create an excellent working environment which promotes teamwork and collaboration?
Sure. The 3 dos I would recommend are to always focus on the customer, do only one thing at a time, and constantly question your assumptions. If you keep your focus always on the customer, you avoid the common pitfall of thinking that you know what is best for them. Developing a successful product or service requires enough humility to know that only the customer can tell you (through their behavior, mind you, not their words) what features/benefits are going to work for them.
There are many don’ts, but I can narrow it down to three: Don’t over-engineer your first version. Don’t build anything that’s not part of your core value proposition. Don’t raise money before you have to.
You’re a real expert on your subject, how did you get here?
I started in technology during the first “dot-com boom” of the late 1990s. I did not study computers in school, but I managed to teach myself enough programming to get a small contract job in web development. That first gig led to another, and so on. After a few years of building websites as a contractor, I transformed my freelance work into a small web development agency. I built a team, and experimented with agile methods until I found a balance that really worked.
My wife and I ran that agency for nearly 10 years, developing a wide range of applications for tons of different industries. I also had the chance, somewhere in there, to do some graduate school for computer science, filling in a lot of gaps in my engineering skills. We shut that business down in 2011 to pursue other things, and I ended up at Change.org
As head of engineering at Change.org, I developed a robust delivery process that balanced Agile and Lean Startup methods. We were one of the first teams to do so--and I spoke about it at Lean Startup 2012. Later, as a Principal Consultant with Neo Innovation, I advised engineering teams at Adobe, App Direct, and Sharethrough, and taught them similar methods.
I have participated in seven startups over the years, and coached countless others. I have also coached product teams in a number of large organizations. That’s basically what I am doing now, as a consultant.
I've given talks on team performance and executing experiments at scale at QCon NYC and SF, AgileCamp Silicon Valley and New York, and Lean Kanban North America. I literally wrote the book on startup patterns, documenting what works and what doesn't in getting from an idea to product-market fit.
Would you recommend hiring an external team of highly qualified professionals to work together with the internal team in the development of your project? Why?
There are many reasons why an external team would be useful. For starters, all of your product teams may already be tied down with other work. If you want to explore innovation, and you haven’t got the right mix of scrappy, smart, entrepreneurial engineers and designers on your staff, you may need to get outside help. With that same portfolio model mentioned above, using an external team to build a new product experiment can solve a lot of bureaucratic problems in the typical company.
Just be sure not do one of those dumb “fixed-bid, fixed-scope” projects. You have to treat the outsourced team like they are part of the family. Make sure you’ve got a contractual relationship with them that prevents any kind of adversarial issues. Basically, *hire them as an extension of your organization for a period of time, not as some “vendor” that has no stake in the business.
Sounds like Xmartlabs is the perfect external team…
(LOL) of course! I know the highly qualified professionals working at Xmartlabs are really helping big and small teams to get their projects into motion in the blink of an eye! They offer remote and on site services, and work elbow to elbow with the company’s team, in order to achieve their goals and satisfy their needs. Just drop them a line and they’ll help you to get started. You can also contact me at [email protected]
