Set us up? OK, there we go. All right. Well, great. Well, let's get going. We have a nice intimate crowd. So we're trying to kind of a little bit different format today. I want to introduce you first to Madhura Meskasky, who is at Platform 9, founder of VP of Product. Before that, she was at Oracle and then did a tour at VMware. And I think she's got a fascinating story to tell everyone for a whole bunch of reasons, which we'll get into in a little bit of the Q&A with her afterwards. But what I wanted her to do first was maybe go through a deck, just a couple of slides, and really tell you her story. And then I'll ask her some questions, as I mentioned. And then it'd be great to open it up to everybody else to get your questions soon. We can talk about whatever people are interested in talking about. And I should introduce myself as well. My name is Ryan Floyd. I'm a founding managing partner at a firm called Storm Ventures. And I've done a lot in the OpenStack ecosystem over the years, including MetaCloud, where I was the first investor there. And there's actually some relevancy to Platform 9, and then a company called Swiftstack as well. So I've been involved with the OpenStack ecosystem for a while. So that's all I want to turn it over to you and walk through your deck. OK, fantastic. Thank you, folks. Thanks for all for being here. I want to start by saying that it's an absolute pleasure to be at the OpenStack Summit here. This is my third time attending the summit, and I was just sharing with someone this morning. Just yesterday, in that one-hour conversations that I had at our booth at the expo, just the quality and kind of those conversations tells me how much OpenStack as a foundation and as a summit as well has grown. Because there is a night and day difference between the kind of conversations I had at the summit I would say about three or four years ago versus the kind that we're having here. So very happy to be part of this community. There we go. So let's start with quick introductions. I am Madura Miskarski. I'm co-founder and VP of product at Platform 9 Systems. And the quickest way to get in touch with me is just DM me at Twitter, Madura Miskarski. You can look me up on LinkedIn as well. So what do I do? I co-founded Platform 9 Systems. And for those of you who don't know what we do, we pioneered a unique way for OpenStack-based cloud deployments, where we deploy OpenStack as a SaaS service. So you can learn more about what we do by going to our website, Platform9.com. Since we got started in late 2013, we've received global traction in terms of customers. We have deployments not only in the United States, but across the world in Europe and parts of Asia as well. And then we've been recognized with several awards for a unique deployment model around OpenStack. Including most recently, we were the proud achievers of Gartner Cool Vendor Award for 2016 for the cloud management space. And I want to highlight that we're the only OpenStack vendor to have been recognized with this award by Gartner. So this session is not really about Platform9 Systems or what we do. But in this session, I wanted to share my story of going from an early stage software engineer at VMware to then becoming a co-founder and having started Platform9 Systems. And I think there is value in sharing this story because for an open source community such as OpenStack, I think startups just add a tremendous amount of value because there is a whole bunch of innovation that happens in a startup that is then contributed to the open source community. And so startups are important. But startups are at the same time incredibly difficult. Having an idea is the easy part, but building the right kind of team around it, getting the backing from venture capital funding, and then executing on the strategy tend to be some of the most difficult parts. So I wanted to share our story of doing this. And I want to say that it's a personal story. So everyone's is different, but here is mine. So if I rewind time back to early 2013 or so when it all started for us, we were just three staff engineers, tech leads and architects as part of VMware's vCloud director team. And we were given this task. We were told to participate in a session for a large customer of VMware's to help them debug a problem that they were running into. And as we did the debugging, we realized that the problem has actually been fixed since. And it's long been part of one of the later versions of VMware's product. So we told the customer, we say, look, we think we should upgrade to the version 4.5, because this issue is already being fixed. And to our surprise, the customer completely refused to upgrade. And they then shared with us that upgrading is not something they like to do on a regular basis. They would rather avoid it unless they absolutely have to. And to us as engineers, it was surprising, because there is so much innovation that happens in every single release or every single version of the product. Why would a customer not want to make benefit from it? But what the customer shared is that because the upgrade experience is so painful, it's so difficult that the return on investment was not worth it for them. So there was sort of a click in our head, which is there's definitely something. There's a problem to be solved here. And on the other hand, we had a friend who started a successful startup company in the Bay Area. And they had grown it from 0 to about 500 employees or so in a relatively short period of time, five, six years. So an example of a very successful Bay Area startup. And like any other startup, they were big users of the public cloud. And so the director of IT, the VP of IT, this one evening, I remember, shared this really funny story with us.  When he sits with his DevOps team, they have this tradition of taking bets on what their public cloud spend is going to be like for that day. And it was just an example of how unpredictable or how out of control their public cloud spend had become that it required spreadsheets and spreadsheets worth of tracking and management. So this is literally how he described it, which is for them, they were driving in a car full speed, completely knowing that they're heading towards a disaster but having no control over that situation. So that really resonated with us again. So we kind of added two and two together. And we were like, OK, private clouds are incredibly difficult. They require dollar, dollar, dollar in terms of costs. It's literally from a customer, it's like jumping down in a bottomless pit because you don't know what you're signing for. And public clouds are expensive. And the best way to run infrastructure software, we believed strongly, was as a service. And this has already been proven in sales, in marketing. There is Salesforce, there's Marketo, there's Workday for HR software. But for some reason, it's not been done for enterprise infrastructure software. And we thought there's no reason why the model does not apply. So we felt strongly that the best way to run software is as a service. And the third thesis that we had was open source is going to eat the world. There are already patterns of this.  All the new technology innovation in the form of Docker containers, in the form of open source platforms like Kubernetes around Docker orchestration, OpenStack, Cloud Foundry, it's all in open source. So we felt that gone are the days when a proprietary vendor software captures more than 80% of the market share. So that was the general thesis. And so based on that, we started estimating for the opportunity. And this was some of the data points we extrapolated based on some of the publicly known numbers of VMware's requirements. So we thought, OK, roughly, there are probably 50 million or so virtual machines that are running in private data centers. And this was at that time. And I believe the number actually is fairly larger. So we extrapolated and said, by 2017, there will probably be about 70 to 90 million of them or so. And this wasn't accounting for the net new workloads that were being containerized. It wasn't even accounting for the net new workloads that were running in the public clouds that were potentially going to move for a hybrid deployment in future. So it's very clear to us that the addressable market is fairly large. And just to add a little bit of color in that, this was a survey run by Information Week. And they ran the survey in 2007 and then in 2014 as well. And this survey represents a pie chart of various virtualization technologies and their percentage in terms of the private cloud workloads. And what's interesting to note here is that in 2007, the percentage of virtualized workloads that were using VMware's technology were about 85% or so. And then when the same survey was run in 2014, the percentage had gone down to 56%. It's a significant difference. So then we asked the question, well, what would it be like in 2020? And our answer was, it's likely going to be a lot less of VMware and a lot more diverse. We'll probably see a lot more of Linux KVM, a lot more of containers. So all these data points kind of adding together gave us enough conviction that we said, OK, let's quit our jobs at VMware and let's start something here. And so this is kind of roughly the timeline that we followed in terms of our first fundraising round. So we left VMware in late 2013. Pretty much right after that, we incorporated. We started at my co-founder, Shirish's home. That was our first office. And then we started looking for funding. We were fortunate, I think, we were able to raise a series A round right away at that time. And then we kind of completed that by making our first hire by the end of that year. So all these things happened pretty fast for us. But there is some lessons that we've kind of learned as part of this whole process that I think are interesting to share. So our first round of funding was a series A round.  In our case, we didn't. And it turns out it was not necessary because we had the background coming from VMware. So from an investor's perspective, we did not need to prove that we could build the product. We were some of the tech leads from VMware's vCloud director, so that helped. The big question that I think a lot of entrepreneurs ask when they're looking to start raising money is to series A or not to series A? Or to be specific, how much money should I raise in what form it should be? Whether it should be an angel round or it should be a seed round or a series A round? We had that debate within our team as well. And I think the biggest learning or the lesson I would share from my perspective, which is that I think when you're thinking about that question, the single most important thing from your perspective should be the time to market for your product. Because remember, for every single week or a month or even a year that you're spending, not taking your product out to market to your customers, you have to remember that your competitors are doing just that. And they're doing that. They're doubling down on it because they have much more funding and many more resources. So that is your biggest challenge, your competition, because you're going to have to work towards it. So my philosophy has always been to figure out what is the amount of money you need in order to build that minimal product and take it to market where customers can start paying money for it and then shoot for a little bit more than that, because you will always find reasons why that initial amount of money was not sufficient. Don't worry too much about dilution, is what I would say it is incredibly important to value that. But the top level priority always has to be to build a long-term sustainable business and whatever it takes you to get to that. So that was the first round of funding. And then with that, what we did was that we built a 1.0 product. It took about a year to do that. And then we released it in January of 2015. We started having first-paying customers right after that around March of 2015 or so. So we didn't have paying customers before. And then we raised our next round of funding in April. So in about a month or so after we had our first-paying customers. And there is some interesting observations there as well which I think towards the end we can talk about. But so somebody of some of the challenges that we ran into as part of the whole fundraising process, the top question that we would get asked both for our series around and for a series around is the viability of OpenStack itself. There were a lot of questions around it. The first time we raised funding, even the second time there were questions around it. Some of the early players were on the path of disappearing. And the market was and still to some extent is dominated by professional services. So the question was whether there is a space for a product vendor in OpenStack at all. That was one. The second one was a very, very common theme which is the fear of Amazon or the public cloud being the be all end all of everything. And this is something that we literally got as the first question, which is are private clouds even going to be relevant in future? Is in Amazon, not even public cloud, is in Amazon going to be the place where everyone runs their infrastructure? And the truth is the story is not nearly as simple, right? It's a far more complex world. And we feel that it's going to continue being so, which is a lot more deployments are hybrid today. And private deployments, co-location-based deployments have their own place. And so we stayed true to that conviction. And then finally, the worry was that will containers just completely obsolete virtual machines? Will there even be space for OpenStack if OpenStack primarily focuses on virtualized workloads? And again, the story is not nearly as simple. Even over the next 10 years, we believe that containers will run side by side with virtual machines because virtual machines will continue to be those legacy workloads, right? So just some of the learnings that we built during this process is, first of all, stay very true to your conviction, right? Don't deviate it. Don't move left and right on it just because you hear all kinds of feedback around it. And then nothing speaks as much as a product that is resonating with customers, right?  So we kept building incrementally. We kept building small. And we took it to customers as frequently and as often as we could, right? So our first prototype was built in about a couple of months from our first round of funding. And then we took it to a whole bunch of customers that myself and my co-founder we knocked on the doorstep through LinkedIn Sales Navigator. So we did a massive cold reach out because we had no sales team. And we didn't want to hire a sales team at that time.  And you get pretty used to this. But you end up meeting a few kind souls who are willing to actually try your product, even when it's that early stage. So build a focused MVP, see if customers would want to pay for it. And then the final learning was from VMware, which is build a product which is as non-disruptive as possible. This is something Diane Green used to say at VMware, which is the reason why VMware's technology is so powerful is because it's the most disruptive, non-disruptive technology, which is it's disruptive in what it lets the customer achieve in terms of that massive wants of server consolidation. At the same time, it's very non-disruptive in how you deploy it, because it does not require any modifications to the operating system, the way VMware's virtualization worked. So you could take your physical workloads and convert them into virtual. So we took that lesson to heart. And so Platform 9's product today works in any kind of green field or brown field environment, regardless of the type of storage, networking, or server software you have. So no HCL, no hardware requirements. And that worked really well for us in hindsight. And the final lesson is what not to do is just as important as what you should do. And as you receive feedback from a whole bunch of different directions, there is new ideas that get added. You've got to stick to your core. So for us, it was important to stay away from SEP, to stay away from Swift, and even Neutron in some cases. Because we realized that each of these projects could sink our entire development team, which was small. And it would distract away from our focus, which was to enable private clouds of any scale for organizations. So we said, OK, for these things, if they end up being important, we will partner with the right set of folks. But we're not going to try to build a SEP storage out of the box or a Swift. So in hindsight, I think just being focused means being able to say no to a lot of things. So that's incredibly important, I think. And so where we are at today, we are about 45 employees. We have 50 plus active customer deployments, some very well-known customers like box.com, et cetera. We've been recognized by Gartner. And overall, I think it has been a fantastic journey for us. In just kind of quick lessons learned as part of that, one of the most important things that I think I learned personally is you have to remember that it's not just the investor that is investing in you in terms of money, but you're investing in them as well. So you have to make sure you work with someone that you're forming a partnership with. Because a great investor offers a lot more than just money. They offer a ton in terms of strategy, customer introductions, advisor interactions, that ends up being immensely valuable. So look for that partnership. Don't look for just a source of money. And then listen to others, but stay true to your guns, for sure, especially during fundraising rounds. There is just so many different deviations to your ideas that you would hear many times from the investor community as well. And so you have to take in what you think is important, but stay true to your course. And finally, just enjoy the ride. It's for sure full of ups and downs. That's guaranteed, but you just got to enjoy every step of it. So that's our story in a nutshell. Cool. Well, great. Maybe just to rewind to the beginning. I think for everybody sitting in the audience, if it was me, you didn't have any entrepreneurial experience. You had been inside of Oracle. You had been inside of VMware.  I mean, you're kind of minimizing it now. It all looks good in hindsight, but it must have been very scary to take that leap, to leave the warm nest of VMware and go out and, to some degree, compete with VMware.  And what advice would you have for others thinking about doing that? Yeah, for me, if you had asked me this question, I would say five or six years ago about whether I would want to quit a job and start a company, my answer would most likely be no. Because I had that tradition in my family, and I'd seen my dad do that, and my brother. And they've had, I've seen what kind of rocky lifestyle an entrepreneur has. So I wasn't sure if I'm cut out for it. But there were a couple of key triggers or changing points that happened for me in my career. I think around 2010 or 11 or so, I was convinced that I've done everything I could at VMware. So I was looking for the next opportunity.  And then I realized none of those job offers were looking interesting to me. It just seemed like much more of the same of what I did at VMware. So I figured there is something a lot more meaningful and challenging that I'm looking for. And as I was doing that search, I realized that in my co-founders who were my friends at VMware, that they were independently going through that exact same journey at that time. I was just lucky for us that we were all going through that process. So then we just started kind of meeting together at lunch, which we already were. And we started just ideating just all kinds of crazy random ideas, which were completely out of our comfort zone where we had no prior knowledge in them. And it took us probably a year or so before we kind of meandered and ended up on this one. So the biggest drivers for me was, I think, that one clear sort of realization that I don't think I can just continue working at large firms anymore. I need to do something different to satisfy myself. And then having found my co-founders. Mention about your co-founder. How I get asked this question all the time about how important are co-founders? What do they do in terms of you thinking about building the business? How important are they? From different answers for different people. But for me, on a scale of 1 to 10, the importance of co-founders is 10 or plus. It's just incredibly, absolutely important. I mean, there are people who do this process on their own. But I would strongly, strongly, strongly recommend finding that one or two kind of like-minded souls. And if you know them, that's even better. And really start your business with them. It's just much easier than with someone else. Because you go through so many lows, as well as highs. And the highs are best celebrated with others, but the lows are best gone through with your co-founders. Yeah, so just on that, the highs and lows, I think you telling the story, it sounds kind of like a Cinderella story, it's perfect. But there are- I'm pretty sure I wrapped it up nicely. It doesn't always, there's good days and there's very, very bad days. Talk a little bit about the highs, but especially the lows and sort of what, maybe some of the lows, some of the experiences you guys have had and what that felt like and how did you kind of push through it? Yeah, a lot of lows early on were for us from the investing perspective. And partly because we were completely new to this picture and we barely even knew how to interact with investors, et cetera. And we hadn't had a good handle on the whole raising funding kind of process. So we were too keen to jump to a conclusion that just because an investor said either took you to the last stage or gave some positive signal even in email meant that they're actually investing in you. And it turns out it's really not true at all. It's really kind of a game that's happened, right? And many people talk about it, but you have to kind of detach yourself to the extent possible and you have to remain completely unemotional and it's not done till you have a final signed term sheet. So we had some lows. I remember where we assumed, we had chosen to speak with only a couple of investors before and we assumed that there was a yes and then very late after having quit, after having started to meet first ties, we realized it was actually not true. That was a big kind of learning. So you're already committed, you're already spending money. That's right, yeah. And we were not talking to anyone else, right? Because we thought it was done deal. And this was when we were working from my co-founders home. It wasn't me, by the way. It wasn't me. It wasn't me. So we definitely learned a big lesson there. So if there are questions in the audience, feel free to jump in. We can take a couple and mix it in. Yeah, go ahead. If you can go up to the mic, actually, they ask so that they can get it on the audio track. So first off, in 2013, I started my own company with a group of friends across the cloud stream networks. And I just want to say congratulations that you were successful because we weren't. So that's the first thing. So congratulations on your success. Selecting someone to invest in you is the most critical piece of the journey. And I wanted you to kind of spend some time talking about how you researched and you found the right VC to kind of who believed in your vision and who was going to support you. Because a lot of people don't understand, well, maybe they do, but it's about that relationship that you have with that VC that's going to really dictate if you make it or if you don't. That's right. No, I think that is just incredibly, incredibly important. And I'm glad you kind of asked that. So I kind of want to go back to this one portion, which is about all the negatives that we experienced while talking to VCs. And one thing that we learned there was you could either take that out or trying to convince them, the folks who didn't believe. And maybe some of them would get convinced just because you had the right background because the background does matter when it comes to investing. And they could choose to invest in you, but whether you want to work with that, those set of investors as a partner is the question. So I'll give you an example. I remember we were pitching the OpenStack as a service model to someone. And at the end of the pitching session, et cetera, the only question that we were asked is, well, how is it different from mesosphere? I was like, okay, maybe it's my accent. Maybe I didn't describe how OpenStack is fundamentally different. But then we went through a full structured pitch again, kind of describing pros and cons, putting it in a table. At the end of the session, I still don't get it. How is this different from mesosphere? So that was a sign for us that this partnership is likely not gonna work because there's fundamentally a difference in thinking. So in the end, the investors that we went with, starting day one, there was a positive relationship. Red Point Ventures, for example, just to be specific, had invested in CloudStack before, so they knew what it's like playing in the private cloud space. So they understood the pros and cons and the benefits and they believed pretty strongly that there is a significant opportunity to be had in the context of OpenStack. And so we thought they were a perfect fit. So I would very highly recommend, and this is the benefit of branching out and talking to as many investors as you can, so that when you have multiple offers, then you get to sort of choose and you get to find the right partner. Actually, you went to the same boat, you went to the same boat, and how'd you find it? Right, good question. You know, we didn't know where to start. We had no prior connections or context in that space. However, because we were from VMware, one of the big benefit we had was the V Mafia, right? There's a whole bunch of X VMware folks who've since started companies. So we just floated the word around and then we got introductions through our friends in the VMware community. And I think what I've noticed is typically for every person, there is some sort of community of some sort that you're involved in. It could be your undergrad community, it could be your, you know, community of the company you're working at. So try to tap into that as a resource as much as possible. You never know, you'd be surprised by how many connections you'll find. Let me just underscore too a couple of things that she just brought out that I think are really key. So the first is, if you meet a venture investor who's not really a believer in the market, you know, you can have a play conversation, but never in my 15 years have I ever seen a situation where that opinion has changed. It's almost impossible to change someone's mind. Because most investors walk into a situation with preconceived ideas about things, right? Whether we want to admit it or not, it's in the back of our mind or in the front, doesn't really matter. But convincing someone against this whole sea of risk and making a decision, if they're not already primed, very, very tough, I've never seen it. Number two, the importance of team. They saw that there's multiple examples here that were just kind of pointed out, but I just really want to underscore it. Not only is co-founders critical in terms of these, you know, the highs and lows, but things like if you're raising money, you don't have a prototype, you need people to believe in your ability to execute. Team is everything, right? I mean, outside of market, team is everything. So it is incredibly critical. And I think people sometimes underestimate the value of that team. And it's not just a belief in yourself and how you may work with others, but it's having a team assembled that others credibly will believe can execute against the opportunity.  And then the third thing is around the introductions to VCs. By far, the best way to get to know or get into a venture investor is through these, you know, a single called the Mafia's alumni networks from companies of other entrepreneurs that have been successful. The phone call I will return every single time is from a CEO in my portfolio who says, hey, Ryan, I've got a company, you really gotta meet with them. I'm gonna meet with that company every single day. That's the best introduction you can get. I think that cold emails can work as well, but I think that you just have to be very directed in terms of what you're trying to do and be prepared to play a pretty broad, you know, number of venture investors sort of get any to hit. But the warm intros are the best. And I'd say venture investors don't really like to admit it, but I would say probably that's 95% or more of deals that get done happen just that way. Because it comes from a trusted source, right? So it's already kind of filtered. And for someone who's struggling every day to keep up with things, that's a great way to do it. Yeah. Yeah, if you just go to the mic and I think that way they can get it on the audio track, yeah. Sounds good. So regarding your first round of investment funding that you had, you said you didn't even have a prototype, right? So how did you value your company and who helped you value that way you can figure out what percentage to give to the investors and what to keep to yourself? Yeah, no good question. So the prototype wasn't needed. I don't think the prototype, and Ryan correct me if I'm wrong, but in our experience the prototype by itself would not make a difference in the valuation, et cetera. But if you had, say a prototype that you'd built over a couple of years and you had customer attraction, that would potentially make a difference, right? So for us we realized that given that we wanted to raise right away we didn't wanna wait for a year and build something, take it to customers that the prototype would matter so much. In terms of valuation, again we tapped into the source that we had, which is we had these co-founders who had just run their fundraising rounds and they kind of told us the typical of what kind of valuation and what kind of share you would not necessarily need to give to investors for the kind of investors that we were talking to. And again it defends, it changes from the kind of investors you're talking to as well, but your trusted network is the best source, someone who has just done it and talked to our, say, four or five people, that's what we did. I'd say too, I mean, state in the obvious it's often very market driven, right? A great team coming out of VMware that everybody believes can execute in a market they believe in is gonna get one price. And a team that's maybe unproven in a market where the non-many venture investors are interested will get another, even though both have equally the same amount kind of done, right? Yeah. So just interested in getting your opinion on this. So you're kind of this gen two company, I think. I sort of think about it as an open stack. There's this kind of first gen of startups, which I invested in a few. And companies like Cloud Scaling, Piston, MetaCloud and so forth, Merantis, phenomenally successful. But it was a mixed bag in terms of exits. And a lot of people have struggled there. What lessons do you draw from looking at what those companies did right, did wrong? Do you think about that in terms of, because you kind of stare at it and know what the, maybe think of it as all your investor meetings, people are asking. And it's interesting too, I should mention, another interesting data point, sorry to digress, that Cloud Stack was a success, all right? It was bought by Citrix. It was a big success. And when people invest in companies and are successful, it's no big surprise. They're interested in investing in more companies like that.  It's not rocket science, right? It's just basic human psychology. So I'm not surprised that Red Point was primed, saw the opportunity and was able to do it. So anyway, with that, yeah, what do you think about that first gen companies relative to you and lessons? Yeah, you know, before I get into that last thing that you just mentioned, I think is just really important, which is when you're looking for your potential ideal venture capitalist firms, look for their history of what companies that they've invested in. And there you'll start seeing patterns of who might be pro your idea versus who might not be, right? And that'll just save you a ton of time because going back to what Ryan earlier said, if they've had not so much success in your space, then their chances of investing you are reduced, right? So it's very important to keep that in mind. We didn't. So going back to your question, it is something we thought of since day one, really. It was a question that we were asked from investors as well. But it was a question to us too, which is some of the early stage companies, say there's a bunch of them, right? Metacloud was a success. They were a great successful acquisition by Cisco and Cisco is doing great things with them today. But some of the others didn't have quite the fortune. So we're asking the question, why was it that they were not successful? Is it that fundamentally in the open stack space, a product is never gonna be successful and the only route to go is gonna be professional services or is it something else, right? And we spent a lot of time just kind of analyzing. We also talked to a whole bunch of customers that was always the best strategy. And what we realized is that the early stage companies had the bad fortune of being a little too early, right? So their sales teams had to spend a ton of time just pitching to customers about what open stack is because the market wasn't educated at all. The market was very early, right? Our experience, and this is the thesis that we made which has been true, is anything but that, right? Every single opportunity that my sales team talks to today is already primed in terms of they already are aware of what open stack is. The CIO is aware, the VPF infrastructure is aware. So the question is what open stack distribution to go with. And if that's not the case, then we put those opportunities on Backburner because we think there is enough fish in the pond that we don't need to head for those early stage ones. And that, I think, was one of the biggest differentiators. There was other differences that we came to a conclusion of that their execution model wasn't necessarily ideal. They were relying a lot on Greenfield versus we felt the best ways to insert into existing deployments. So there's a couple of those things, a couple of the timing and the execution where we felt we had a significant edge. Great, any other questions? So, okay, sure. Otherwise, I got a lot. I don't want to hug, but I got a bunch of questions. The other thing that comes up is that with the company that I had, we didn't have a prototype, we didn't have patents. Part of the team was really solid, part of the team wasn't. So the biggest thing was customers. When they were evaluating us, what came up when we were looking for funding is how many customers do you have that are using it? And customers almost became the currency to which we were gonna get evaluation. So for you, you talked about how you went into LinkedIn and you did this blast out. How many customers did you have by the time you got your first round of funding? And then by the time you got the second round of funding, how many customers did you have? Looking at customers as a currency to prove that you have a valid solution in the market. Right, yeah, no good question. So when we raised the first round, we had no prototype, we had not built any product for a reason, because we were at VMware and it was also some conflict of interest. So all we had were about four or five, I believe, customers that again, we had reached out, who were prior VMware customers, who we thought had the relevant pain point. And those customers were willing to stand up and take a call for us from investors, saying that I haven't used their product obviously because there's no product, but I can validate that this pain point in use case exists, and it exists for me at scale. So for our first round of funding, that was sufficient because we had a team and we had an execution strategy. When it comes to the second round though, it was a completely different picture, right? When we were raising our series B round, there was significant traction to be demonstrated in terms of customers, paying customers and not paying customers and so forth. And we didn't have paying customers right away because our product had only gone GA about a couple of months before that and nobody pays you when you're in beta or it's rare, right? And that was, we did think that that was one of the challenges which is, we didn't have immediate paying customers because we had just gone GA. Fortunately for us, we went past that right away. Over the next couple of months, we had some pretty big wins and that kind of helped. But I would say for your first round of funding, it may or may not be that important. That's given my experience. If you have the right team, then you don't need to demonstrate active customers. But from then onwards, customers is going to be your most important currency. So you have to kind of work towards that. Great. Well, it just looked actually, it's 240 times flew by. So listen, I want to thank you very much for taking the time and putting it all together and sharing the story. I think it's a great, I'm just super excited that there are new startups coming into the, the open stack ecosystem as an investor. I think it's, I think it's great. And thank you all for coming. If you have any other questions or thoughts, I think you know where to find us and thanks again. Yeah. Thanks everyone. Thanks.


Why do constipated women appear to be at higher risk for breast cancer? Results suggest a slight increased risk of breast cancer for both decreased frequency of bowel movements and firm stool consistency.  This could be because constipation means a greater contact time between our waist and our intestinal wall, which may increase the formation and absorption of fecal mutagens, substances that cause DNA mutations and cancer into the circulation, and that could end up in the breast tissue. This concept dates back more than a century, where severe constipation, so-called chronic intestinal stasis, was sometimes dealt with surgically, figuring that the colon was an inessential part of the human anatomy. Why not cure constipation by just cutting it out? What they noted, though, was that potentially precancerous changes in the breasts of constipated women seemed to disappear after the surgery. It would take another 70 years, though, before researchers followed up on the clues by those distinguished surgeons who claimed that breast pathology cleared when constipation was corrected. So they investigated the relation between potentially precancerous changes in the breast and the frequency of bowel movements in nearly 1,500 women. They found four times the risk in women reporting two or fewer bowel movements a week compared to more than once daily, who had the lowest risk. We know that even the non-lactating breast actively takes up chemical substances from the blood, so maybe substances originating in the colon might enter the bloodstream and reach the breast. We know there are mutagens in feces, so it's not unreasonable to suggest that potentially toxic substances derived from the colon have damaging or even carcinogenic effects upon the lining of the breast. And those toxic substances may be bile acids. First shown to promote tumors and mice in 1940, subsequent experiments on rat led to the mistaken belief that bile acids just promoted existing cancers, but couldn't actually initiate tumors themselves. However, there's a fundamental difference between rodent models and human cancer. Rats only live a few years, and so the opportunity for cancer-causing mutations may be at least 30 times greater in humans. Now we have at least 15 studies showing that bile acids can damage DNA, strongly suggesting that they can initiate new cancers as well. Bile acids are formed as a way of getting rid of excess cholesterol. Our liver dumps bile acids into the intestine for disposal, assuming our intestines will be packed with fiber to trap it and flush it out of the body. But if we haven't been eating whole plant foods all day, bile acids can be reabsorbed back into the body and build up in the breast. Carcinogenic bile acids are found concentrated in the fluid of breast cysts at up to 100 times the level found in the bloodstream.  By radioactively tagging bile acids, they were able to show that intestinal bile acids rapidly gain access to the breast, where they can exert an estrogen-like cancer-promoting effect on breast tumor cells. This would explain why we see 50% higher bile acid levels in the bloodstream of newly diagnosed breast cancer victims. These findings support the concept of a relationship between intestinally-derived bile acids and the risk of breast cancer. So how can we facilitate the removal of bile acids from our body? Well, we can speed up the so-called oral anal transit time, the speed at which food goes from mouth to toilet, because slowed colonic transit can increase bile acid absorption. We can do this by eating lots of fiber. A diet packed with plants greatly increases bile acid excretion. Fiber can bind up and remove toxic elements like lead and mercury, as well as cholesterol and bile acids. But plants can bind bile acids even independent of fiber. Vegan diets, for example, bind significantly more bile acids than lacto-ovo or non-vegetarian diets even at the same fiber intake. Which could explain why it appears that individuals eating vegetarian might excrete less mutagenic feces in the first place.


Around Dodge City and in the territory on West, there's just one way to handle the killers and the spoilers, and that's with the U.S. Marshal and the smell of gun smoke. Gun smoke. The story of the violence that moved West with young America. The story of a man who moved with it. Matt Dillon, United States Marshal. Need any more cartridges, Mr. Dillon? No. I got the greener loaded. Unloaded. I don't want a shotgun. Yes, sir. Do you want me to come with you? You want to come? No, sir. I guess not, but I will. Better stay here then, Chester. This make me a coward, Mr. Dillon. How do you feel? Like a coward. Lasseter scares me, sir. But you were willing to come anyway. Figure it out for yourself. Good luck, Mr. Dillon. Yeah. If, uh, I'm not back, don't forget those reports have to be mailed tomorrow. I won't forget. Mr. Dillon? Yeah. You ever get scared? Sure. Better keep yourself busy. Hey, man, did I walk along? Not at all, Doc. Yeah, kind of anxious to get a look at this new corpse of mine.  This will put us in the history books for sure.  Not a bit. Oh, maybe a little foresight it had.  He sure has been a lot of gunfights. Yeah, so they say. Mm-hmm. Guess he's got the biggest gun rep in this whole section. Outside of maybe Ben Thompson or Wes Harden. And you, of course. He's waiting at the Alifraganza, Doc. You better not walk in with me. Oh, don't you worry. I'm not sticking my snoot into no shooting. No sirree. Hey, Marshal. Yeah, what is it?  I sure hate to work on the bodies of my friends. Makes it too non-personal. I'll do what I can, Doc. You watch him close, Marshal. You're learning to pull a hideout. Hello, Lasseter. Hi, Matt. Been a long time. Yeah. Drink with me? Why not? Harry, two whiskeys. Harry, get up from behind the bar. Sure, Mr. Lasseter. Sure. Oh, don't spill it. Leave it on the bar, Harry. We'll pour our own. Yes, Marshal. Yes, sir. Here, sir. How's your shoulder, Lasseter? It aches a little, bad weather. Still carrying your lead, Matt. There you are. You should have killed me, Matt. Maybe. It was a long time ago. Matt, I want you to know I bear no grudge. But it has to be. I know. We're gunfighters, you and me, both the same. Yet not the same. But it's in our blood. That's why, Matt. That's why I have to brace you. I got to know for sure. There's no grudge, Lasseter. Hey, your health. And yours. Straight up. Straight up. You call it. Now. Ah! It was beautiful, Matt. Simply beautiful. Was it? Why, yes, and it was close to. For a moment, I wasn't sure who it was. Oh, Marshal. Your neck. You're hit. Just a scratch, it'll be all right. But here. Let it go.  He's all yours. Hmm? Oh, well, of course. And you'll be happy to know he's got 20 slugs in him now. I couldn't tell anyone, but the bitterness ice in my stomach made me sick as I remembered Lasseter as a friend, not dead by my gun. Then I got over it. I always got over it. The frontier code was a harsh one. I knew my job was one that had to be done if the rest was to ever see peace. As long as killers like Lasseter lived, I'd carry a gun and use it. That was the way it had to be. Sometimes a man's dying was the end of it, and sometimes the beginning is something worse. Marshal Matt Dillon? Yeah? What can I do for you, Miss? Die. Miss, I don't know. It's Mrs. Mrs. Lasseter. You see? You've done quite a bit for me already, Mr. Dillon. You've made me a widow. Sit down, Mrs. Lasseter.  No, thank you. I, uh, I didn't know Lasseter was married. Would it have mattered? No, I guess not. You're just like all the rest of them. A killer. Lusting for blood like a wild animal. Mrs. Lasseter. Only your words. You hide it behind a badge. My husband was in town less than two hours, but you couldn't wait, could you? You saw your chance to get a little bigger reputation. Matt Dillon, famous gunfighter. Matt Dillon, murderer. It was your husband that sent to challenge Mrs. Lasseter. I'm sorry for what happened. And if I can help you in any way... No, thank you, Mr. Dillon. I only came to tell you that you haven't heard the end of the Lasseter name. I'm going to see that you're stripped of that big reputation. And you're going to die. Mrs. Lasseter, is there anything I could say that you would listen to? Nothing. And good day, madam. Till we meet again. Marshall.


The objective of the planning step is to estimate the total manpower required to perform field construction management functions. Decisions must be made as to how far in advance to plan and what methods to use for planning manpower needs. Planning may be confined to the current year or be done for future years as well. How far in advance effective planning may be done will depend on the reliability of the construction program. Planning for manpower requirements for future years shows the trends for the number of employees needed to handle the work programmed. Knowing the trend allows time for training, transfers, recruiting new employees, or reducing forces through attrition rather than by layoffs. The planning method should relate the work to be done, staking, inspecting, and documenting with the needs in the contracts. The planning methods selected will depend on the amount and reliability of data available. Consideration should be given to the type and size of contracts normally awarded. A recent analysis of selected highway construction contract awards showed that 29% of the contracts were for amounts in excess of $500,000. These contracts represented 84% of the total dollars obligated. These contracts will require the bulk of the construction management staffing. Projects of this size require more lead time for design than smaller ones. Three planning methods have been developed depending upon the level of available data. They are based on defined contract quantities, defined contract limits, or programmed dollar amounts. The methods selected should provide a reasonable degree of accuracy and be based on the best contract information available. First, let's look at planning based on defined contract quantities. This planning method provides the most accurate manpower projections. It should be used when detailed contract quantities, such as tons of asphalt paving, or bridge span lanes, are known. This method relates the contract quantities to specific activities. Next is planning based on defined contract limits. This is the next most accurate method. It should be used when contracts or programs are at least defined in terms, such as roadway miles, but when detailed quantities are not available. This method relates the contract limits to activity groups. The third method is planning based on programmed dollars. It is the least accurate method. It should be used when the only known information is the estimated cost. The dollars are converted to contract limits, such as roadway miles, by means of cost standards for each contract type. Next, you will need to select contract types. The number of contract types used should be the minimum number needed to distinguish contracts. The grouping of contracts should be based on type of construction and contract characteristics. Only those contract staffing similarities representing a major portion of the construction workload need to be identified as contract types. Smaller jobs may be handled by grouping them into a miscellaneous contract type. Each unusual jobs command special considerations in a unique classification. A general guideline may be followed when selecting contract types. The number of significant contract types should represent approximately 75% of the number of contracts and about 90% of the dollars in the construction program. Also, contract characteristics affect the progress of the work and therefore the manpower requirements. Major factors include the difference between rural and urban locations, terrain, mountainous or flat, and working with traffic control through the work zone. Two master lists of contract types have been compiled. One list for planning with detailed contract quantities and the other list for planning when only major characteristics of the contract are known. Both sets include major contract types as well as minor contract types, which represent significant portions of the workload in most areas. Each agency should evaluate and modify these lists in relation to its construction objectives. Only those contract types which best describe the workload should be used. Smaller contract types, which are used infrequently, should be included with miscellaneous contracts to keep the number of types to a minimum. Once contract types have been selected, planning activities must be determined. Planning activities are used to define work that must be performed by field construction personnel. Two sets of planning activities have been developed to define engineering work for any construction contract. They are developed for individual activity or by activity groups. The level of construction detail will determine which set should be used. Individual planning activities should be used whenever detailed contract quantities are known. The number of activities used should be the least number that will provide sufficient detail for reasonably accurate planning of the workload. Over 300 separate activities have been identified in some agencies. However, 80% of the total man hours used in those agencies were on about 35 activities. The remaining 20% can be combined in miscellaneous activities. A master list of typical activities has been compiled. It is intended to cover the significant activities for most agencies. Each agency should modify this list to fit its own work methods. Planning units of measure are used to relate construction work requirements to the scope of the construction contract. Planning units of measure must be selected for each planning activity or activity group. The units define the engineering work required for each activity. Work requirements are related to the characteristics of the contract through the planning units. Most individual staking activities are related to the linear characteristics of the roadway, stations, or roadway kilometers. While inspection activities are generally more dependent on the contract quantities. Quantities should be readily obtainable from contract plans or other existing work documents. For example, if asphalt paving is paid for by the ton, use tons. Roadway kilometer is the linear length of a roadway of independent or relatively independent alignment. Multiple lane, divided, or undivided highways are considered as two roadways. 7500 cubic meters is a bid item quantity, which is used for earthwork inspection and testing on construction contracts. It includes excavation, embankment, sub-base, and all other earthwork on the project. 1,000 metric tons is a bid item quantity, which is used for asphalt paving inspection. 1,000 square meters is a bid item quantity, which is used for Portland cement concrete paving. 100 square meters is a bid item quantity, which is used for joint repair on Portland cement concrete pavement. Span lane is the number of spans multiplied by the number of traveled lanes of each structure with a clear span of 6 meters or more. It is used for structure inspection on major contracts. Bent is the number of substructure abutments or pier locations. It is used for structure staking on major contracts. Span is the number of spans on a structure with a clear span of 6 meters or more. It is used on bridge repair contracts. Lump sum is used for special features on major or unique contracts. Working day is the number of working days estimated for the contract to be completed. It is used on the minor contracts, intersection improvements, and landscaping. There are also recommended planning units of measure for activity groups. For roadway construction, use kilometers. For bridge construction, use 30 linear meters. And others include working days and lump sum. Activity groups should be used when only major contract characteristics are known. Their primary use will be with small contracts. Those which require very little time in the pre-construction stages. The groups consist of the four functions of construction management. They are staking, inspection, office engineering, and project management. In this course, we have covered the planning element of designing a construction management system. The objective of this element is to estimate the total manpower and other resources required to perform field construction management functions. Three planning methods are typically used. They are based on defined contract quantities, defined contract limits, or programmed dollars. When selecting contract types, follow the general guideline, which says the number of significant contract types should represent 75% of the number of contracts. And about 90% of the dollars in the program. When selecting planning activities, keep in mind that typically 80% of total manhours used are used on about 35 to 40 activities. The remaining 20% are best combined in a few miscellaneous activities. For more information on this or other IRF videotapes, write to the International Road Federation or call the numbers on your screen.


1. The global burden of disease, GBD, study assesses health losses from diseases, injuries, and risk factors using disability-adjusted life years, which need a set of disability weights to quantify health levels associated with non-fatal outcomes. 2. The objective of this study was to estimate disability weights for the GBD 2013 study. 3. To achieve this, we analyzed data from new web-based surveys of participants aged 18 to 65 years, completed in four European countries, Hungary, Italy, the Netherlands, and Sweden, between September 23, 2013, and November 11, 2013, combined with data previously collected in the GBD 2010 disability weights measurement study. 4. We used paired comparison questions for which respondents considered two hypothetical individuals with different health states and specified which person they deemed healthier than the other. These surveys covered 183 health states pertinent to. This article was authored by Professor Joshua A. Salomon, PhD, Juanita A. Harzma, PhD, Professor Adrian Davis, PhD, and others. We are article.tv, links in the description below.