All right, let's take a look at how this process of evidence-based innovation can work for business to business products. Enable Quiz is our fictional company that we've been kind of playing with as our start-up example. And you're probably familiar by now with their basic proposition. They think they want to create a lightweight quiz to help HR managers screen engineering candidates. So that they can figure out, okay, yes or no, to extent to which the candidates have the core skill set that the functional manager wants for the position. So, what would be a good MVP for them? We talked a little bit about it previously. There's a couple. One, concierge MVP would be really good. They could create a set of, even pencil and paper quizzes, on a position-specific basis for the HR managers, and then just see, do they actually use it if we do this for them? Do they ask us to use it for the next position? Did the functional manager get fewer unqualified candidates and fewer candidates overall that enabled them to move forward and spend time with the candidates they were interested in? So, the moral of the story is you don't need a lot of technology. Now, I mean, Google Forms or something like that might be a little more convenient for everybody, but the point is that it's not necessary to start building a full scale software application. And here's another kind of related question. Let's say they pass this first experiment with a result that says, yeah, they liked this. The HR managers found this valuable. They're asking us to sign-up. They're perfectly happy to pay us whatever they think they need for the service, $50 a month. Well, which topics should they use? Because it's not necessarily the topics that they used in the concierge MVP. Those may or may not be representative of the market at large. So for instance, should they make quizzes for UNIX or Ruby or Java? Or what kind of programming languages, environments, tools are going to get the most uptake initially? A good MVP for that might be a very classic sales MVP, where they run Google AdWords. So they say hiring Ruby engineers versus hiring .NET engineers. These are different programming languages. Hiring devops administrators and so forth. They can pick their top 20, whatever it is, topics, run these ads, and then compare the click-through rates on them. So which have the most uptake, and which ones have the best overall conversions to, let's say, a sign up? That might be a good MVP vehicle to test which topics are going to be the most pertinent for them. Leonid Systems is a company I started in 2007. And the basic problem area that we approached was, telecom operators were transitioning from kind of mainframe-type systems. To voice over IP, and real time communications applications that ran on web servers, basically the same way that most Internet infrastructure runs now. So this was very disruptive to their IT systems, the products they were selling, the kind of roles that they needed to administer these sort of systems. And I was really interested in the IT part of this whole thing. So how were they going to redo their systems for customer care, and billing, and web portals for the users to maintain their service, things like that? And so, I never raised any money for Leonid, I just bootstrapped it. And the vehicle I used was consulting. And if you're in a business to business venture, whether it's internal or a startup, consulting is a great way to scale something up. So we started with consulting. It was me and myself, in the beginning. And we looked at what problems were of interest to the customer, what they wanted to hire us to come in and do. And then we looked at, which one of these do we start seeing a lot of in the market? So what types of engagements do we do on a highly repeatable basis, and how do we build up some know how and process and intellectual property around that? And that made the consulting part of the business more scalable, more profitable, easier to staff. And as we were going through this, we were continually getting more intimate with specific problem scenarios that look like they loan themselves to propositions with software. So we build very simply focal versions of these initial products early on, very much in tandem with customers, and they were sold as soon as they were published. And this was a great way to scale the business up and make sure that we had a nice close view of whether these things were valuable to the customer or not. And if so, how? And this general type of approach of starting small and iterating up based on the value you find, is a really great way to keep your start-up healthy. And so, that concludes our review of these business to business examples. I hope this give you some ideas that you can apply to your design sprint that you're going to execute to test motivation.
