 Since we have a small enough room, I have to speak into the microphone, even though there's only like 10 of us here because they're recording. But I can introduce myself personally and just find out who is here. So I'm Ryan Zorama, the CTO for Commerce at Commerce Guys. We are a Drupal company with two business units, Platform.sh being a hosting platform and then of course the Drupal Commerce business where we build and deliver Drupal-based e-commerce products and services. In the room do I have, I know that there are some business owners who actually like sort of drives the strategy of a business here, whether in a technical capacity or a business capacity. Just a few, somewhat, yeah. And then are we developers mostly or, yeah, yeah, okay cool. Good, good to have you. This is only the second time in my life, come on in, that I've made it into South America. I have been to Ecuador as well and I still carry around my llama purse that I bought 13 years ago. As my laptop bag, it's sentimental but I love being here and it's certainly been a pleasure so far to eat and drink and explore Bogota. So to introduce myself personally, I am married, father of two and really all that my family gets to enjoy and eat and the house we get to live in is all thanks to Drupal. My career basically began at the point that I discovered Drupal. Prior to that, I was selling blenders on eBay. So I started actually writing an e-commerce product for Drupal called UberCart which may be familiar because it started in Drupal 5 back in 2006 and it was not like there was no business behind it but we had a cool logo and a lot of character. And we really just kind of did services here and there but mostly just embraced the Drupal community and learned what it looked like to build an e-commerce system in community which basically looks like a lot of feature creep or scope creep because everyone has an idea about what it could do differently or better. And so it wasn't bad though because I learned a lot and got to learn from some of the best people in the Drupal community like Dries and Larry and Eaton and Earl Miles who created Views and Mosh who did the Migrate Watch, all these guys that really kind of helped me learn and grow as a developer and then also as a business person. So in 2009 at DrupalCon DC I decided to actually build a business around Drupal based e-commerce. At the time it was UberCart and I had two partners that we signed the paperwork in our hotel room in Washington DC and officially launched the business there. And then quickly at the end of that year we had a successful e-commerce project with a French company called AF83. Did anybody go to DrupalCon Paris? Josh, you did? Yeah. AF83 were some of the organizers and they had a Drupal team, about 45 Ruby on Rails people and 15 Drupal people and so their Drupal people came out. We merged to create commerce guys, headquartered in Paris and then now we have offices in London and in Ann Arbor, Michigan in the US. The whole point behind merging and joining forces was to raise venture capital to build Drupal based e-commerce products and deliver services as well. So the money was spent at least initially scaling the team, so hiring sales staff and some project management. But then over time we were able to use more of the money building out our own products using Drupal or for Drupal. And of course it all began with Drupal commerce and that was launched in 2010 to basically replace UberCard as a more flexible framework on which we could deliver websites but also build products. So before I talk about the specific products that we've tried and failed to develop or are developing and have launched, I want to just take a step back and think about the different categories of Drupal products. Because I think I'm not really sure what a Drupal based product looks like to you. One category that I think we're all familiar with would be the full Drupal platform. And this is where Drupal developers create a hosting and development platform for Drupal developers and it's oriented around optimizing development workflows and DevOps and introducing tool sets like Drash and Drashmake which is at the heart of platform to manage your code base and really these are tools that you could never actually build them with Drupal but all of them host Drupal websites and other types of sites like WordPress and we host just bare bone symphony applications and others. But this is one product category that I won't really be talking about in this session because honestly to build something like this requires vast amounts of money. I know that Acquia has raised some $75 million today, Pantheon has raised about 30, Commerce Guys has raised about 10, this is just the scale of money you need to be able to hire engineers and have them build a big platform over the course of many years. It's just very expensive and it's not personally interesting because I actually like to run Lean, I'm more a fan of bootstrapping and the Lean startup and so we get to where I see Drupal being useful for that. But the next type of product category is really deeply integrated tools where there's a third party tool that would have applicability to Drupal users but because it's not integrated well it's just not used by our community. So Vellachi, does anybody know Vellachi or Automator? I'm not sure how far their reach extends. Vellachi was really the first Drupal business to specialize in SEO in content marketing and search engine marketing. They really specialized in that but wanted to escape the never ending cycle of services delivery and get into product development where they can have recurring revenue and predictable sales. And so they found an automated marketing solution and they deeply integrated it into Drupal and call it Automator. And so I think for about 500 bucks a month or wherever they start you end up with really robust marketing tools built into the back end of Drupal integrated into rules, into your views, displays and all that stuff. So you can basically customize the whole front end experience of the website based on what you know about your visitors and your customers. Aquia Lift is a similar tool that Aquia has developed for site personalization and I'm sure that there are others that I'm missing. Now getting closer to where I have a personal interest is NodeSquirrel. Has anybody heard of this? This is basically a module with a value added service. So the people who created the backup and migrate module have reused that to back up our site database and download schedule automated backups. They actually created a service called NodeSquirrel where in the module itself you put in your API key and you can automatically back up your entire Drupal site off site to their cloud servers. So it gives you redundant backups, they're off site so if your web server goes down and your backups aren't destroyed with it. And I think there's some other interesting like workflow opportunities. So imagine for example a development project where you create a site, you back it up to NodeSquirrel and then somebody else is able to restore your precise version of the site using NodeSquirrel into their local environment. That can be kind of interesting. But what they've done is they've taken a module that they developed and maintain and actually put a business model right into the module itself and it's actually a very valuable service that is actually doing really well. And then we come to what Commerce Guys has actually done one of and a few other folks have really gone big on and that's Drupal Distributions. And we probably don't think of Drupal Distributions as products because you don't have to pay for them. We all know that we can go to Drupal.org and download the RedHin profile, the Commerce Kickstart open atrium. And there's not like an inherent business model to a distribution. Now one thing you could do is decide to host the distribution and charge someone to maybe access a locked down version of open atrium or if you consider Pantheon they actually let you one click install a variety of installation profiles and I happen to know that they make decent money doing so because we're in affiliates and we actually get money from Pantheon on a monthly basis based on our referrals for people that are using Kickstart. So there is money to be made but the distributions themselves don't have an inherent business model and historically they've been more of a lead generation tool for a services business than something that someone's just made a lot of money on. And I'll talk about our experience at Commerce Guys when I get to that slide. Finally and this is actually what I believe to be the most exciting opportunity for Drupal based product businesses. You have the Drupal based software as a service. So this company here is Bioreft. I met the owners at DrupalCon Barcelona in 2007. They're still going strong. They're actually hiring and growing very rapidly right now. And what they did is they decided that Drupal would be the perfect essentially application portal to service a market that they knew which was laboratories. So laboratory compliance and testing and accounting and just everything that goes into running a medical or research laboratory. They have used Drupal to create an application portal for them. And you can even see it in the word here in the marketing, Bioreft modules. Every new feature that they put into their platform is actually a module that an individual user of the system can turn on and off. And they actually developed this on the backs of live customer engagements. So they have I think a dozen or so modules right now. And each one of those modules was funded directly by a user of their portal. They had to develop some upfront, of course, to attract customers. But then you sign a contract. Well, I like your platform. If it did this one thing, I would be able to use it. Okay, we'll write that module for you. And then make it available to every other customer on the platform. And they're actually very open about that. I can't recall if it's in this particular screenshot. But they talk a lot about the fact that this is community developed software that's helping all of their customers do better at their business. So when you pay to have something developed, it is then available to the other customers as well. And I think that this is a very exciting strategy for Drupal-based product development. And I'll talk more about why later on in the presentation. At this point, is there anybody that can think of maybe a product or a product category that I've forgotten or missed? No worries if you can't. No, Carlos, no, no, okay. I just, I nailed it, everything. Well, let's talk about what commerce guys products have been. And what my experience from the inside has been building Drupal-based products. First of all, the products we never launched. It's very, very unlikely that you've heard of either one of these. The first one was a product called Checkout Monitoring. And we actually owned, for a while anyways, the domain checkoutmonitoring.com. And we announced it at DrupalCon San Francisco. And then we proceeded to never develop it at all. And the idea behind this product was we were the maintainers of Drupal Commerce. We were at San Francisco to talk about this, to talk about the future of e-commerce on Drupal. And we're trying to think about value added services that we can bring that maybe directly extend our module somehow much like the node squirrel option that I showed earlier. And the idea was that you would have essentially an uptime monitor for your checkout form. So if it ever went down or somebody ever encountered unexpected errors, you would get an immediate text message that says, oh, your checkout form is broken. And this coupon code that you thought was valid is not working. Something to that effect. It's a decent idea, and it could have worked its way into some sort of an analytic circumversion rate management solution. But we ultimately just never invested any time in developing it. And our CTO, Damian Torneud, was just completely busy on client work. So there was really no product vision, no resources available. And we eventually just stopped talking about it. Which is a shame because we actually did have some early traction. We did one thing really right with this product, which was before we started building it, we started advertising it, which seems counterintuitive. But there's no point in us building this if nobody even would ever want to use it. So we did a massive mailing list at DrupalCon San Francisco. We didn't do much to market it. But we had a mailing list of hundreds of people that were interested in being notified when this solution became available. And so even though this product didn't launch, that was still something we did right. So positive lessons from everything. The next thing was Silhouette. And I actually was really excited about this product too. But never launched. It got a little bit further though in the sense that we hired somebody to actually plan out and build the product. Randy Faye worked for us for a while. And I think Randy Faye probably has a good reputation in Latin America. No, you don't know him? Oh man, Randy, oh yeah, you live in Houston. No, Randy, he lives in Colorado. And once upon a time he rode his bicycle from the top of Canada down to the bottom of South America. But he said by the time we got to Argentina I was tired. So instead of continuing on, they lived in Buenos Aires and for six months just worked on Drupal projects from a laptop. He's a really incredible guy. He actually, he's really good. I love Randy. And so Randy came in and he specced out this project Silhouette, which was a PCI compliance assistance tool. The idea being it's impossible for Drupal commerce as an application to be PCI certified. Because Drupal, just by its very nature, contradicts the requirements of PCI regulations if you wanted to use it to actually retain credit card information. So that's why Drupal commerce projects do not retain credit card data. They use card-on-file mechanisms, off-site payment solutions, et cetera. But what we would do with Silhouette was somebody would go to the checkout form and redirect it to our payment server where we would then request the HTML from the Drupal site, present it from our proxy server so that it looked like it came from the customer's actual website. But you could securely put in credit card information. We would pass it straight to the payment gateway. And then you would go back to the Drupal site, not even knowing that's what happened. And that's why we called it Silhouette. So the idea there was just to mitigate some of the requirements around payment data transmission. What was great about this was that Randy spent a fair amount of time specking out the complete solution. And this was the most detailed product plan we ever had. It spelled out exactly how we would build it, exactly how we would market it. And I was really excited about it. But then we got this sort of premature legal insecurity because somebody saw somewhere that someone had patent pending on a similar service. And oh, PayPal is interested in this. And these other companies are doing it. And so the rationale was literally, well, we don't want to get sued or have to suffer a trademark or patent thing later on. So let's just not do it, which is really like the wrong attitude. Because first of all, that's purely hypothetical. What we were doing most likely would have been different from what anybody else was doing because we aren't stealing anything from them. We actually came up with the idea on our own anyways. And if you get to a point where somebody's suing you because you have copied them and have threatened their market, well, that means you're doing something right. You've actually made a big enough business to become a threat anyways. So really, I would never scuttle a future product because I thought somebody might not like the fact that I was developing it. But what we did right there was we did very carefully plan out and document and prepared to build a product. Ultimately, we didn't move forward kind of sad. Randy left as a result because he didn't have any interesting work to do then. And we carried on and switched our focus to Commerce Kickstart 2. And the idea behind Commerce Kickstart 2 was to take Drupal Commerce in a variety of contributed modules and turn Drupal into an e-commerce application that would compare head to head with a solution like Magento or Zincart or PrestaShop or the other open source e-commerce solutions. So Kickstart 2 is very good for the Drupal community because it showed how to build a lot of different things using Drupal Commerce, like faceted search interfaces, fancy product catalogs, responsive checkout forms. And also we used a lot of views, customizations on the back end, developed a lot of modules that are now used outside of Commerce Kickstart. Really, it was good in many ways for the community. And it was also good for our business because it actually did open up a new revenue opportunity for us that we did not necessarily consider ahead of time. So it's a Drupal distribution, and like I said earlier, distributions have no inherent business model or value. But what we discovered was that thousands of people were using Commerce Kickstart either to learn how to use Drupal Commerce or to actually launch real stores. And I can think of a few dozen examples of stores that took Commerce Kickstart, implemented a new theme, and launched a site, and brought great value to the merchant for very little overhead or little upfront cost. So we were able to basically take this market of users and developers and begin to bring in third party service providers like Authorize.net, Lingo Tech, Shoot Fastly, Mail Up, and a variety of other services that they do something essential to e-commerce, whether it's email or payment or fulfillment or security. And we then helped them market directly to our users. And as a result, they would pay us marketing money, they would pay us integration costs. And by the end of it all, I would say that Commerce Kickstart, while it hasn't been profitable, was at least a break-even proposition. But it did cost us much more and take much longer to develop than we ever anticipated. And at the end of the day, it's not actually the best solution for launching most new Drupal Commerce sites. It's good if you really fit like 95% of the features it implements, but in general it's better as a recipe tool, a demonstration tool, maybe a sales tool, but not necessarily a development tool, which is what we actually still need internally. So it's good that it broke even. And when I say break-even, I would estimate that we probably spent three or $400,000 over the course of its life cycle, employing developers full-time for six to 12 months to really build it, customize it, design it, do usability testing, all that kind of stuff. That we spent a lot of money developing it. And at the end of the day, break-even, but not something that you would ever build a business on. And that's what we're talking about, is actually growing a Drupal-based product business, not making neat tools that kind of pay for themselves, but don't really get you anywhere. So the next thing in the Commerce Guys product catalog was platform.sh. And this is great. Oh, never mind, it's not this bullet point. Well, it's great for that reason too. It's a very technical product that implements and really enforces what we consider to be best practices Drupal development. And not only does it do that, so using Drushmake files and a build process that supports automated testing and other things. But we even kind of made a technical leap in allowing the same Git repository that controls your Drupal site to also control the configuration of your services. So PHP, MariaDB, Solar, et cetera. The memory limits, the extensions, and other configurations you can manage directly from your Git repository. So whenever you push or commit up to your platform, it actually recreates your entire environment, those services included, and rebuilds the Drupal code base and then it makes the site available again. I couldn't think of a simpler word for that. And it also cost more and took a lot longer to develop than expected. We started announcing it at DrupalCon Munich, which I think was 2012. And we didn't really open it to the public until June 2014. So just last year. So two years after we expected it to be available, it was available for self-service. We put our first enterprise customer on it at the end of May. And so it just took two years longer than expected and it was much more technically complex. And I think another thing is we rebuilt it twice before we launched it. Not helpful for getting to market. At the end of the day though, it's a very strong platform and it does drive recurring revenue to our business, which is really the foundation of Commerce Guy's future growth. And honestly, the only reason an investor is going to give you money anyways. But it's still a long ways off from breaking even. Not only because we had all of our three years of development costs, but even going forward, we still have to support a team of Python engineers and a support staff and a sales force that's just all really expensive. That said, platform.sh is for me the most interesting aspect of Commerce Guy's future as a product business, simply because it has a natural inbuilt recurring revenue model and it's such a robust tool that it does lend itself well toward enterprise projects and the like that pay a lot of money to have solid platforms. So just a few lessons learned from these. I'm gonna put them all up on the screen. First of all, if you want to build a Drupal-based product, well you have to start building it. There's, I can't think of many good reasons not to at least prototype something because prototyping is cheap for us in Drupal, but for various reasons, it was managing developer time, managing resources. We just never made it happen and there comes a time when you have to decide, well, I think I'm just going to go ahead and try something because I think that many of us want to have some sort of a product that is generating recurring revenue and sort of giving us more opportunities for the future. And really you just kind of have to start. I actually started a little side project on the airplane down here just because I've been thinking about it for months and months and I finally said, all right, I've got an hour, I'm just gonna start building this. And once you begin to make progress, that sort of breeds its own sort of sense of motivation. But the other thing is to solve a simple problem first and then build complexity only if you need to because for both commerce kickstart and for platform.sh, we were solving very complicated problems and we were solving them before even having anyone using them, before even knowing who would use them or why. So I mentioned checkout monitoring had a very clear value proposition and had people that were interested in learning more about it upon its launch. For commerce kickstart and platform, neither of those was the case. These are both full solutions that had to be developed over the course of years and then launched and hopefully somebody would find them useful. But if we had gone to market with a simpler solution first, we could have scaled our development maybe more intelligently, maybe come to market faster. And so when I think about the future of Drupal-based products, I'm thinking about things that really drive towards simplicity, not change your life all in one fell swoop and do anything imaginable under the sun for an e-commerce project or something. And then also I think, like I said already, that there's a better way to leverage the tools that we have, even with commerce kickstart. We use the features module to manage the configuration of all of the different parts of commerce kickstart. And we didn't even leverage that in the best way that we could have. And it backfires because once somebody uses commerce kickstart to build a site, if they customize any of these components that are wrapped up in features, they can no longer really update from one version of commerce kickstart to to the next without probably undoing something or at least not getting new changes. So I think there are better ways to use the tools that we have. And I think that a lot of the things that Drees mentioned in his keynote with respect to Drupal 8 really pushed Drupal forward, as in my opinion, the ideal application framework. So has anybody here built a Ruby on Rails application? No Ruby developers? I've tried back before I got into Drupal. I actually was looking into Ruby because my boss who tasked me with creating UberCart was interested in it. We ultimately went in Drupal because we wanted more out of the box. But Ruby on Rails is kind of the darling in the startup community because it makes it really easy to scaffold a web application or a new API. And so I live in Greenville, South Carolina, and there's a startup accelerator there. And every other startup that comes through is based on Ruby on Rails because they can create an API in minutes and then throw a bootstrap theme in front of it and then start collecting data and doing something with it really, really fast. So it's a very, very fast rapid prototyping tool that does a lot of the scaffolding for you. And part of the reason it's so good at that is because basically once some people started doing that, well, a lot of people sort of piled on and also used Ruby on Rails as a web application development tool. And so then just by having more people doing the same thing on it, the tooling got better and better and it got easier and easier over time. And I think that Drupal 8 is really putting the Drupal community in a position to where we can really kind of replace Ruby on Rails and perhaps Node.js in some cases as a go-to tool for creating new web applications. So what are we good at in Drupal? First of all, rapid prototyping, even through the user interface is something that we do better than any other tool. You can quickly create your data model, quickly create your different presentation layers, and quickly create a web service or REST API based on what you've just done. One of my ideas that I haven't just built it yet is called likeshed, and the idea is it's just a storage container for the things that you like on the internet. Using maybe perhaps like a browser plugin to record, anytime I hit a Facebook like button or retweet something that has a link in it or upvote a link on Reddit, it just puts all of these into one sentiment storehouse where I can manage all of the things that I like on the internet in a bit similar to like a delicious or a bookmarking service, but it's actually based more around maybe non-tangible actions that you might take. Anyways, if I wanted to, right now, I could prototype that by creating a content type that has a URL and a user ID, that has views that show all of the things that are in my likeshed, and then has a REST API where I could then integrate that into other websites and then maybe start selling myself products based on the things that I like all over the internet. And I can literally build that all in Drupal without writing a single line of code, and then I can export it all to features and then manage it as a product. And I can do that. Now, I personally wouldn't adopt that approach, but I could if I just wanted to prototype it and prove the model. And so we're really good at that in Drupal. And another thing that we're really good at is managing code and configuration in our VCS. And also testing changes before deploying them because we have these platforms as a service that enforce best practices for DevOps. And we also have modules like features that let us export configuration into code and manage it in our source code repository. So we're really good at this in Drupal. And I'm not sure what the equivalents are in other communities, but this does play into our ability to rapidly prototype and manage a Drupal-based product. Finally, we're also really good about access control. So the Drupal role system and permission system and then a variety of other modules and things that have been built on top of that. Such as content access, access control lists, organic groups, and a variety of other things make us an ideal tool for giving privileged access to certain pieces of content on the site and then licensing out that access to that content to different consumers of the web service. And thanks to Drupal Commerce, even billing for usage of these services and access to these APIs. So we're really good at this in Drupal, which is why products like Biaraft are so cool because they're basically taking all of Drupal's strengths and using Drupal to build a product that solves problems that they've surfaced in their target market. So it kind of depends on you either having clients or having personal experience in the market you're trying to target so you know the problems, the pain points, and can have access to people to propose solutions. But assuming you can find those either through sales or personal relationships, building the platform out to solve those problems using Drupal is a very rational course of action and in my opinion it's a very strong course of action. I actually consult for a friend's business where he didn't have much of like, there's no content management requirement in his product. There's really not much of anything that you would typically think of as a Drupal feature. And so I thought well maybe we could build this out using Node.js and Express and let's just make a custom Node app to serve up all of your content and reports and analytics. And I began doing it, I was like wait a minute, how do you even manage user accounts here? Okay what about an interface for resetting your password? Okay how about email solutions and so on and so forth? All these things that I take for granted in Drupal I realized I didn't want to have to build from scratch. I said look just build it using Drupal and get all of this for free and because we can alter anything you can certainly alter the stuff out that's not relevant to your business or just not enable those modules. But basically it lets you, once you have a solution you want to develop quickly build it and then start selling it. Additionally, Bioref is cool because they were able to introduce features based on customer demand and use the Drupal API to roll them out in a modular fashion. So picture if you will, you maintain a distribution that represents your product and you make sure that it's upgradeable from release to release to release and every time a new release comes out maybe it has a new module in it that you can then turn on for your customers but you don't give them access to the back end. You just say look if you want to enable this module that's an extra $50 a month, you do that for them and it's just using the Drupal tools and concepts to shoot charge for the additional features that you're developing and rolling out for your customers. Anyways, what's also cool about this is that they followed customer demand. They didn't just imagine they knew what everybody in their market needed. They waited until somebody had signaled I will pay for this and then developed it and then turned it on for them without impacting all of the other users of their software. So I really think that they provide an example for anyone to follow and I think that this is true even if your market is much simpler in their requirements than medical testing laboratories handling biohazardous material or something. So for example, I haven't fully fleshed this out but one of my strategies for the future is to never build a Drupal website ever again because I'm tired of building websites where I go get Drupal and I grab some modules and I throw them up on someone's server and say hey good luck with that maybe once in a while I'll check in and make sure everything is up to date. Instead, my wife actually needs a website for her doula business. She's a labor coach and assist women in delivery and so she wants to be able to share her stories, market to pregnant moms in our area and so she needs just really simple content management functionality but instead of just building her that site I'm going to create for her a distribution that I just begin to maintain as my own product, my own Drupal distribution that if anybody else in my family needs a website they're getting that and not something that I'm building from scratch and then having to maintain for them and I really came to that conclusion at Drupal Get-In. You guys know the phrase Drupal Get-In where the Drupal 7.32 had this really bad security fix in it so you had to go and update all of your sites immediately and I realized I had one friend over on HostGator not in source control, I had two of my own websites on DigitalOcean, one of them still on Rackspace and a few here, there and everywhere, two on Pantheon and I think I had one on PlatformSH as well so literally like it was insane to have to go through and update all of these different sites in all manner of different fashions and so I realized that I could treat even my own sort of personal customers as my target market for somebody that wants a product that delivers a simple content editing experience and simple brochure website for example and so we're actually going to take this philosophy to create a new foundation within CommerceGuys for the work that we're doing because as I mentioned before, Kickstart 2 is not a sufficient starting point for our majority customer which is someone with a B2B website, a digital commerce website or in many cases just someone that has a lot of different services they integrate with on the back end and they don't even use the website itself to administer their product catalog or orders or customers. It's just, there's too much that you have to turn off and because of the way we built the features and because of the way we manage the project it's hard to take CommerceKickstart 2 and turn select things off and replace them with other modules. It's just not the best experience and so we're going to start from scratch with essentially a new internally managed distribution of Drupal that actually gives us a launching point for these projects and instead of taking the Kickstart 2 approach where we just imagine what would every B2B website in the world want out of our platform we will build it up over time as clients demand new features, implement them in our internally managed distribution and ideally begin to sell what are called managed e-commerce engagements so that's where instead of paying you $50,000 to build a custom e-commerce website somebody pays you a smaller amount on a monthly basis and some percentage of sales and the trade-off for them is they don't have to make as big of an upfront investment and your revenue is basically tied to their success and that's for an e-commerce company that's a much better long-term strategy than starting every month at $0 in sales having to hit at CommerceGuys, I can't even remember, a few hundred thousand dollars in new engagements on a monthly basis and just starting over from scratch every single month if you can begin to amass a pool of clients that are based on recurring revenue that you can actually improve their website and drive new business to them and therefore profiting more yourself it just creates a much better symbiotic relationship so we'll be doing this internally and ultimately we will want to narrow our focus in the future so once we have the base functionality covered which anybody can do this I mean CommerceGuys is doing this I'll be doing it for my personal websites blogs and that kind of thing and you can do it for any of your customers as well eventually we'll have all of the usual things covered like pretty invoice emails, faceted search you know again turnkey solution for that and then we can choose to narrow our focus and create a solution for a specific vertical market and you know right now I could say that one of my ideal ones is private content websites where somebody is selling white papers or analytical analysis reports or even just access to content on the website itself because we've had many different customers that do that and they all need the same things it's the commerce modules with commerce license with the content access module or the commerce license file module you put it all together and there is in there a turnkey solution that you could actually market as a software as a service for analyst companies to sell their white papers and once you do that it actually becomes easier to sell because you actually have a target that you're throwing darts at instead of just saying well I'm just gonna do any e-commerce project you can't really build a sales campaign around any e-commerce because you need some target in some way to narrow your focus so that you can actually chart your effectiveness as a sales force okay so I actually have already been doing this like I said I have my friend's company Bellwether where he is building an application portal for power companies because he was an energy analyst he developed a new model for weather normalization and he wanted, which is just a part of the energy forecasting process and he wanted some way to just deliver his analysis to his customers I said oh great here's Drupal I can rapidly prototype for you in application dashboard that only people from these companies have access to and since I know how to use Drushmake and I know how to create a distribution I know how to write modules you can manage all of this in source code and turn it on, turn key for every single one of your customers on their own version of the site and keep them all up to date as you go and it's actually happening it's very similar to Biaraft although I don't know exactly how they manage individual customer portals the strategy I advised them on was just one Drupal site per customer you could do it a variety of ways depending on the type of product you're building but it's basically proven in the model I think it's worked I think it's working for Bellwether and what's making it work is not not sort of building something and hoping somebody will then come and find it and use it but rather going out there and I just had them call every utility they could think of and find somebody who needed their tool or something similar and eventually they closed a couple of projects around tracking outages for power companies and delivering better weather forecasts and things like that so similar, very similar to Biaraft and really my preferred strategy for growing a Drupal-based product business and the reason being and these are the tools that I would recommend or the resources I would recommend for you to learn more is because it's iterative it's based on direct customer feedback and it's bootstrapped, it's running lean so the idea here is a guy named Ash Maria created Running Lean which is his paradigm for iterating your way from plan A to a plan that works so he says you start every new product that you're developing by identifying a problem and then proposing a solution finding enough people to say yes I would appreciate the solution to this problem then you develop the solution and then figure out how to market it which is how much do I sell it for who do I sell it to how do I reach those customers and all that and so in this book he literally goes through from the very beginning all the steps that you would need to build, grow, scale a product business and it's specifically written around softwares of service businesses although it's applicable to other types of products and he even did something funny which was he used this book itself as an example so before ever writing the book he actually created a landing page where he said I'm writing about this who wants an advanced copy and he basically committed to himself that once he could convince 1,000 people to join his mailing list then he would begin writing the book but he wouldn't write it all at once he would write chapter by chapter by chapter get feedback on each chapter as he went and finally end up with an in-product that was first published himself as a PDF e-book and then eventually got picked up by O'Reilly and now he's on second edition and he's begun to develop a whole set of products that are based around his running lean paradigm and one word here is that yay though I am a part of a venture backed startup I do much prefer at least right now the lean startup method which is to not just go raise venture capital and try to build something because the potential for like a misalignment is high so one of the things he says is like running lean it's not about being cheap and trying to develop a product without ever investing any money but it's about being one efficient with the resources you have but also not bringing in external investment prematurely and he has really close to the beginning of this book and I highly recommend it if you're at all interested in building a product business he basically shows on a graph where you have the different steps in the life cycle of the product I already mentioned them it's identifying a problem developing your solution that would fit that problem then finding a product market fit and then once you know that you have a product that solves a specific problem then you scale it because it's at that point that you're actually ready to go and just basically take money to invest in reaching the market that you already know exists you've already proven the product is valuable and worthwhile but it's at that point that you want to start scaling out your resources because if you do it earlier the money works against you because your investors are looking for a return at the wrong time when you're still needing to rule out products and rule out solutions and rule out strategies you know somebody's looking to see you growing successively year over year and so I really recommend this book and I also recommend this tool it's the Lean Canvas you can try it out I think it's still free at LeanStack.com and what it does is it gives you a one page business model where you can sit down and identify from top left to around what problem are you solving what's your solution how do you identify success for people that are using your solution what is therefore your unique value proposition which is somehow a combination of all these things and before you embark on building this product what is it that gives you your unfair advantage so why would somebody buy your solution to this problem over somebody else's this is something that's hard to reproduce ideally so you aren't you know disrupted once you begin to prove a market and then he also has you know segments that deal with who are my customers what are the channels through which I'll reach them and what are my revenue streams once I can reach them so this is a one page business model that's a good practice for you even in evaluating the different things that you think you might want to build because if you're anything like me I have a notebook full of product ideas I just like something comes to me I write it down and you know eventually I'll get around to basically making a canvas for each one and then I can decide well which one do I invest my time in and it's gonna be the one that you know looks looks best on paper ideally but also it's gonna be the one that I have an immediate revenue opportunity for so like with Bell whether it was power companies needed a service so the tool came second and then you know that the actual product then you know sort of can be developed from there and another thing to bear in mind she Paul does anybody read Paul Graham he's part of I think Y Combinator it's a startup accelerator in California but he has a really good blog post that I recommend and it's it's called do things that don't scale so the idea is that when you're building a product out from scratch you you you have to be willing to you know basically use yourself and your time and your resources in ways that wouldn't scale so they wouldn't be right once you have your product market fit you wouldn't continue to do things that don't scale while you're trying to scale that's kind of counterproductive but but in the in the beginning you know you could actually take your business model and you could actually you could accomplish it without building a single thing so in the case of Bell whether the first customer wanted to correlate number of customers without power per hour so so at nine a.m. on June second two thousand ten how many people didn't have power correlate that to wind speed and precipitation and then basically determine how how weather influences power outages over time and so the analyst that sort of developed this whole model uh... you know he's he is delivered he is hand-generating the reports using our the programming language uh... from scratch putting the the results into a word document printing as a pdf and emailing it to the customer obviously could not do that for a dozen different customers but because he only has only one until he can do all that automated through some web system he can do that and and make his fifteen hundred bucks a month because he's able to do so you know just just because you have like the the sort of grand vision on paper doesn't mean you can't begin doing things up front that don't scale i i i've heard of things i think it was striped and uh... paul graham talks about it in the in that article they would literally like hand into credit card data for it no no i don't know what they were promising that whenever you signed up for stripe you would get a merchant account and it wasn't that like stripe integrated with some merchant account provisioning api they would literally just take the customer's information and very quickly go into it into a form uh... and and and create these merchants accounts for their customers but you know for the customer they wouldn't know that it was just the founder of the company doing it by hand uh... but that's how they were able to get new business and then automated over time to scale uh... finally uh... there's a resource called predictable revenue uh... and uh... predictable revenue is is basically uh... a crash course on creating a winning sales strategy so if you have a product and you want to take it to market this book tells you exactly how to do that uh... from scratch with no assumptions whatsoever about what you know about sales and it's written by the guy who took sales force dot com from zero dollars in recurring revenue to one hundred million dollars an annual recurring revenue and he basically uh... identifies all of the key activities uh... and all of the the types of people you need to have you know to scale out a new business uh... but it but he just he doesn't such whether it's broken down it's it's very clear it's very useful he talks about uh... a strategy called lead prospecting which is essentially the web two dot o equivalent of cold calling uh... but cold calling still works you know if you know what your target market is you can get a phone book and you can call people and so he starts you know even there and just just basically provides the strategy that took sales force you know to one hundred million dollars in revenue and it actually has uh... worked out wildly successfully for a successful jupy company you may have heard of if i can see at least one shirt here uh... on the front page of predictable revenue dot com uh... aquia is a prime case study because i was essentially reproduced the exact same success uh... acquies revenue uh... is powered by the predictable revenue methodology and it's also taken them up to essentially a hundred million dollars in annual revenue uh... so highly recommended and in fact i'm timber trend it writes articles about this like i thought we have you know one of their strategies is is to give back more uh... jesus tell me this is part of their DNA they want to give back more and that extends to every area of their business not just contributing to the jupy software but even educating all of us on how they do what they do and and tim's article around how they're using this model to sell their products and services is is very enlightening and i highly recommend you you know take advantage of that i mean that they even share sales numbers they sell their strategies they we know exactly what are we has done to generate their success and the good news is that it's it's literally like it's not rocket science it's just discipline and the the tools and methodologies in both running lean and predictable revenue will give you your start now granted octrea raised a bunch of money to do what they've done to scale so quickly uh... but i think for many of us the at the uh... the draw is more of a lifestyle business where we can build and maintain a product that supports you know our lifestyle doesn't necessarily make us a public company although if that is also your strategy these are still the same tools that you would use to get there and one more thing uh... i i i i i i said before i really believe that the droop late will be the ideal platform for creating new applications and uh... i i i i feel strongly about this one because of configuration management which trees talked about which gives us a very uh... just just a better way to manage all of the things that we can figure and put into code uh... but also because of the rest for web services module in core uh... giving us much better rest api support out of the box than we've ever had in dupal seven uh... so if you're if you're considering do i want to build a dupal based product uh... maybe will it have an api uh... maybe uh... maybe one thing for you to do would be to start learning dupal eight now and plan to prototype it on dupal eight uh... instead of either using dupal seven or building it from scratch in some other framework because as with the ruby on rails community the more of us that decide you know dupal can be this tool for our products than the the better the tooling will get in the simpler will be for all of us to continue to do this sort of thing uh... and that is the gist of my presentation we got five minutes or so here to take questions uh... if there are any including secrets about commerce guys if you want to know numbers the dirty details i'm happy to dish i in that case i'll make myself available afterwards if anybody wants to talk or brainstorm discuss ideas uh... also josh is going to be talking about conversion rate optimization in uh... not just dupal commerce but also just in general uh... that will be in some other room in fifteen minutes out across the hall in twenty minutes at two fifteen and then if you're interested in the future of dupal commerce on dupal eight uh... i'll be presenting that on behalf of the unsavvanova at some it's after there's a good coffee out after the coffee break somewhere else upstairs somewhere all great fantastic right so thanks a lot for your time and uh... you know the other