Andrew Levy
From Dev to Enterprise Sales

Andrew Levy is co-founder and CEO of Crittercism a mobile APM solution. Previously he was the co-founder of AdThrow, a Y Combinator company that specialized in real-time ads. Before YC, Andrew was an HP engineer working on enterprise data warehousing software. At HP he led teams specializing in agile programming methodologies and advocating rapid product iterations.

Collapse
00:00:00
00:00:00

Alright, thanks. Happy to be here. I recognize definitely a few faces in the crowd.

I'm the co-founder and CEO of Crittercism.We're a mobile application performance management company.It's interesting because APM has been this acronymthat's been around forever.It seems like the newer age of developersand DevOps people actually don't know what it means.It's interesting because that's the target marketwe're going after is enterprise companies. There's definitely been this transitionthat we've gone through and I can talk about that.Part of those transitions have also involvedthe messaging and marketingwhich we can get into as well.

Just a little bit about Crittercism.We've been around for about three years now.We first launched our product Summer of 2011.It's essentially an agent or an SDKthat's embedded into mobile apps.It sends off real time diagnostic dataabout performance issues.Developers or operations folks can log into our portalwhere they can consume the data,we help them triage, troubleshoot.We do a very in depth root cause analysis, if the user was trying to buy something and it didn't work,if maybe they couldn't add something to a cart.We provide a ton of data to recreate those circumstancesand then the hope is they can quickly turn around a fix.

I guess the other things to mention hereare our revenue.I deleted some of the private data. We haven't released revenue numbers,but we have grown pretty significantlyand Gartner has also recognized usas indeed being the leader in the industry.That's a little bit about us.We do support iOS, Android.We have something for HTML 5,we support some third party platforms,something for Windows phone.

It's definitely been an exciting journey along the way.We've grown very quickly. What I'm going to do is actually walk you throughyear by year starting in 2011 and just share some of the learnings as we've grownand what's worked and what hasn't worked.

If I was to show you the beginning of our slide decks todayit might look something like this, but back in 2011 it was more like this: We have the cute critter up there.It says "Support Platform."You should take notice to the word platform because when we originally started the company,it seems like a little thing,but we'd call ourselves a tool.

No one wants to be called a tool for many reasons. Platform sounds bigger, sounds sexierand that's how we were positioning ourselves.

You might think support,what does that have to do with performance management?Early on we thought it was one product.It was really two products.We had this crash reporting thingand we also had this widget forif you're using a mobile app it allowed you to submit support ticketsessentially through the app.We ended up taking a look at our dataand one of them wasgrowing much more quickly than the otherwhich was the crash side.It took us much longer than we should haveto actually deprecate one of the two,but we indeed ended up doing that.

I'm going to get to how we actually grew ourselvesand made the transition. I just want to set the stage for how we got some initial tractionand maybe some of that will be relevantto the stuff that you guys are working on.Really, 2011 in summary, we were just focused on building product,getting lighthouse customers on boardand doing unscalable things.

In the early days, we just wanted to prove outthe product market fit.Here's an early graph.One of the beginning slides said that we were onsomething like 800 million devices.Back in 2011, I think the number says 100Kand then it goes up.We're in the tens of thousands,hundreds of thousands devices at this point. It was just friends and familythat we were reaching out to.

We had gone through an incubator similarto what you guys are doing.We just tried to get as many people as we couldto use the product.We were sending e-mails in the form of,"Hey, so and so why don't you come and try out the product?" We had a beta list.We created some artificial demand by setting up that list.

We found early on, actually, to be this magic number of five.What I mean is we set up a waythat you could add team members.We found that for whatever reasonas soon as any one of our customers added fiveor more team members that there was justexponentially more usage in that account.Actually, I think that wasa great early learning for us.

When we were setting up our pricing tierswe never wanted to discourage adoption.I think if you look at some products, they sell seats,like number of developer seats or what have you. But I actually think it'snot the right approach necessarily.

You really want an organization ALL in on your product. Especially the Valley is very fluid. Many people will join a companyand move onto something else,and you want those people to be your advocates.That's exactly what happened to us.

Early on we got the early customersthat did manage to come and use our product.We found that one person would be ata very large video streaming providerthen go to a financial services company. And guess what?We maintained that relationshipand they brought us into that account as well.

We also found that doing somethingas simple as adding Google OpenID sign-in was huge for us, making it that much easierto get customers on board.Actually funny enough, we've been wanting to addGitHub for a long time and we haven't.I still think we should.We just haven't gotten it scheduled for whatever reason.

There are some flip sides to that.When we first launched,we launched Summer of 2011.We announced our fundingand at this point I had mentionedit was a lot of long tail developersand small companies using it.We quickly had some great inbound enterprise interestonce we announced our seed funding. Part of it was that we had some great product market fit.You know, to quote Paul Graham, "the hair on fire problem" we were attackingwhich was apps were crashing.

At this point, by the way, we hadn't transitionedto a full application performance management platform.It was still basic crash reportingwhich was really our wedge into the market.We managed to find that wedge which was great.Companies were just looking at app store reviews.They were doing these crazy workarounds.We heard stories of LinkedIn hiring contractorsto use their apps in Kansasto see if it was working correctly.People were throwing phones in microwavesto simulate faraday cages.

You see people doing silly things,and you know you have a great productwhen they don't have to do those things anymore.

To circle backto the point I was making beforeabout adding team members, adding Google sign-in.One issue is that once you do that,it's a little bit harder to seewhat company they work for.You'll get a bunch of Gmail addresses.It does ease adoption.

The other thing by the wayis that as you grow and you start adding sales reps,you'll need a way to be able to identify those accounts. There are some automated softwareyou can use to do that, but you'll also need a way toroute those leads to different territoriesas you start building out territories.From the beginning we actually didn't ask for a phone number.Having an area code would actually let you knowwhat territory that customer is coming from.

There's always dropoffswhen you add more fields to a sign-up formso obviously that's something to pay attention to. I think we did the right thing early on not having that as a required field. I don't even know if we had it at all,and we would just kind of manually reach outor maybe we did set up someautomated marketing campaigns. Today, you do need to enter a phone number.It's a small point, but it actually helps usimmensely when we can't identify the accountor we need to be able to route a lead.

We ended up getting our first big accountstowards the end of that first year that we launched, December of 2011.At that point they're actually in trialso they didn't start paying until January of 2012.We did have zero revenue for this year, but that wasn't the goal.The goal was getting lighthouse customers on board,getting our metrics up.

Early on, again, it was a lot of manual stuff.It was stuff that wouldn't scale.We also didn't really know the price to chargeand we felt like there wasn't a lotof past precedent to look at.

One funny story. Well,it's funny looking back, it was not funny at the time, was with Smule.They're a game developer.They make Magic Piano and a bunch of other great apps.The Ocarina app, if you use that one.They were another shock to the company.They were introduced to us through an investor, really interested in the product. At the time we had no idea how to price this thing. There was someone else at the companythat was there for about two months,and he moved onto something else.

We ended up working on this crazy spreadsheetwhere we would factor in price elasticityand just some crazy calculationsthat looking back made no sense whatsoever.We ended up giving them a quote forsomething like 40K a month, something ridiculous.Something so absurd that the CEO called me upand grilled me. Not only because that's an absurd pricefor the state of the product at the time,but also because they werea referral through an investor. They were expecting some kind of discount,and certainly that wasn't what they were expecting.

We learned a lot from that.We learned we couldn't charge 40K a monthat that point which was great.By the way, that has changed for us nowas we've added more product and whatnot.At that time we at least knew a ceiling. For Netflix, we were luckywe didn't run into that case.We did present a pricing schedulethat was based on volume.It made sense for them — as they added more subscribers, they grew, everyone made more money.That became actually one of our biggest accounts for a long timeuntil the past 12 months.They were no longer our biggest account.

One other side note was actuallyone of our first paying customers was in Europewhich presented some compliance stuffthat we had to deal with.At the end of the day it wassome great logos that we put upand some great metrics we were able to generateto get us to a series Awhich we needed to sustain the company.

I realize I'm probably running a little bit long on timeso I may not touch on everything here. I guess the last thing I'll mentionabout product market fit,before I start talking more about sales,is that the** pain point** we were addressingwas really focused on all developers.It wasn't focused to a particular niche or to a particular vertical.

I think that was really helpfulbecause we would with open armswelcome any applicationthat wanted to be on the platform.We really had to try to search out the communities.

Actually, when Heroku,and thanks to him for Heavybit,they did a great job of really engagingwith the Ruby community.It was a very tight knit community.This wasn't the case with mobile. It may not be the case with thetypes of developer communitiesthat you all are targeting.

We really had to search them outand we did some crazy things like, and you can't steal this onebecause I think we're still going to do it, we sent the development teamspacks of marshmallows with marshmallows guns and critters. Of course, we ended up getting tweetswith people holding the gunsand doing crazy, inappropriate things with the critterswhich was exactly what we wanted them to do.

The other thing I guess is thatit's hard enough to get people to add codeto their existing code base,so that's part of your business model.We tried to make that as easy as possible.We would literally put the exact Find-A-Code in the docso they could just copy and paste.It would be auto generated based on their data.I think that worked out really well for usas well as just dogfooding our own product.

My wife is an engine developer.She uses our product which is interestingwhen you go home and there's bugsand your wife is yelling at you.It was still a great way to test it out early onbecause we were focused on building a product for developers,but we didn't have our own mobile app. So that was kind of a great path to testing our product more deeply.

Alright, let's switch gears a little bit.

By the end of 2011 it was time for usto hire our first non-engineer.I think many of you have teams of engineers.We got to the point where we really felt like we needed someone out there.I was running around trying to dosales, marketing, BD all by myselfand I was still coding at that time as well as my co-founder.It just wasn't scalingand it was time to stop doingsome of those unscalable thingsand hire non-engineers.

We hired a generalist which worked out for a while.We can talk more about thattowards the end of the session. But the fact is, if you do hire a generalist,you're going to eventually have to hire a specialist.You'll have to hire that VP of Sales,the VP of Marketing.Someone who's an operations person.That can create potential conflictsif you end up hiring someone that comes in early onto just do a little bit of everything.

We also hired a VP of Sales.We got really lucky, it was through our network.I think if I was to give some adviceon how to find your first VP of Sales,it needs to be someone who's a leaderbut someone who's just also a really great rep.Someone who's a great outside repthat can really put some automation in place,put some systems in place,but also get out in the field,know how to convey the value of your product.

These people can be very hard to find.I would take your time.It's really importantand it was one of our most important hires I think.

We also hired a VP of Marketing.They all came in around the same time,but it became clear thatthis was going to be a very exciting market.We needed to raise awarenessand that was the reason.

Here's a timelinein terms of how we structured things.We had three employees, just the co-founders in January. By the end of the year we had seven.At that point we had jumped frombasically zero to 25 million devices.That's compared to the 800 million number a year today.We had some great early tractionand we moved beyond that initial build product to get to lighthouse customers phase.I mean of course, we're always building product,but that initial phase to 2012.

And 2012 was really all about land and expand.We wanted to get into every major account we could.We obviously still didn't knowwhat the exact price should be.We were still doing some testing.All we knew is thatthere were companies out there like Turner, AT&Tthat had hundreds of groups and mobile appswithin those companies, huge amount of brands.

What we wanted to do is getat least one or two of those brands using usand then upsell the account from there. By the way, that's exactly what we did.

Our VP of Sales at the time,this is kind of interesting, since we didn't really have a sales teamwe just assigned him a straight commission — a percentage off of the sales that he was doing. Then some of the initial people that he hired, who were junior inside reps, really helped him get additional leverageas we got more and more interest for the product. That only scales so far.

You can't just take a percentage off your top lineand give it to someone.It worked early onwhen we didn't want to bother coming up with a commission planor any type of structure.Eventually, we did have to setupan on-target earnings, an OTE,that included a base comp plus a commission.

He also did a great job of moving us awayfrom just selling features.Early on when we would do a demowe'd say something like, "Look,you don't have to go to the app storeto see all those bad reviews."Well, actually, we didn't even say that.It was even worse than that.We said something like, "Check this out.You can get some sweet real time crash reports.You can check out all your performance issues.It's great.You can click this buttonand it does this, this and this."

What he did a good job of was coming in when he's talking to a customer,saying stuff like, "Don't you hate it when the CEO's app doesn't work,and he comes and he maybe prints out a bad reviewand he shoves it on your desk and he says,'Hey, fix this,'and you don't have any data to go back thereand nothing is actionable.You don't know how many users it's impacting.Using our product, you can actuallytake the top 10 issues,put them into your sprint,cut off 50% of your problems right away."That was a much different sale than saying,"Look, you can filter by app versionand you get all these data,and look, you get some diagnostic data."The story approach worked much better.

Of course, we also put some more automation in place.I think I was using Google Docs or Excel spreadsheetsor maybe I was trying out Zoho at the time. We just really weren't puttingthe leads that we were getting into a systemthat sales reps could utilize. So we moved to Salesforce which is not cheap, but it's worth it.Every sales person basically todayknows how to use it.It's what they're used to usingif you're hiring someone that's experienced.At the end of the day, it's just not worthhaving them train on something else.

I guess the last thing I'll mention is thatthis land and expand approach was great, but we did run into some problemswith the contracting early on.We had our own paperwork,we had our own contracts that we gotthat were form letterheadsfrom attorneys or whatnot. A company like Turner,they want to work on their own paper.Yes, as an aside,if they do want to work on their own paperyou could try to command a higher pricewhich some companies do.I know some analytics providersin the Valley do that.

This in particular is badbecause we didn't actually have a contract attorney.Let me take a step back.We did have a contract attorney,but we were using our corporate attorney.We were using the same attorneythat we used for fundraising.We ended up racking up a huge bill, something like larger than our series A fundraising bill,just to close this account.We use Wilson Sonsini.They were nice enough to actuallytake some money off the billwhen we showed them what had happened.

The point is as you start having to work more and morewith customers under contract,get a contract attorney.Get someone independent.It won't offend whoever else you use.It's completely normal.We just took too long to do itand we wasted some money because of it.

The other thing to mention is thatfor a long time we just had basic and enterprise. Part of the reason waswe were still testing out pricing,we weren't sure what it could be.Eventually, we set up a long tail,kind of a premium upgrade tier. At that time this was targeted towards developersthat wanted to pay usbut were more of the independent type.

The corporate customers, the enterprise customerswould go for the enterprise tier, which I think also worked at this time.It did give us actuallyat least a few hundred paying customerswhich was great early onin terms of the metrics or datathat we wanted to show to investors and everyone else.It did create some problems early onwhich I'll get into in a second.

The other thing to mention is thatwe did billing in arrears.I don't know how many of you are developing — you have developer-focused products.If you're not selling seats,you might be selling based on usage or volume.This became a bit of an accounting headache later on. We'd have a 30-day period.At the end of the 30-day periodwe would send them a bill.

The problem was we started doing thisin a way that whenever they signed up it started that 30-day period,which may not sound too bad. But if you think about it,if you're trying to close out your books for a month,you charge someone, let's say someone comes on boardat the end of July.That means you really won't know until Septemberwhat to charge thembecause you have to wait until the end of August. Because of that the books for Julytake forever to closeand we had to do some fancy estimationsof what we thought the average contract valuewould be for that customer.

It just created a bit of a financial headache.We ended up moving everyoneto just the first of the month.We did some prorationand we still build an arrears for the volume,but made sure we started at the first of the month.

I mentioned I'd get back to some of the problemsthat the premium tier introduced.By this time, Fall of 2012,we did have at least a six figure contract or two,and our ACV was starting to go up. But you could imagine,if you're a customer paying six figuresyou'd go to our pricing pageand you see $25 a month.You may kind of turn your head.What are these guys doing?What am I paying for?Is there some price discrimination here?There is an anchoring risk.

I'm a big fan of putting pricing up on the website, but you have to realize thatif you still have a tier that's not exposedfor enterprise customersand it's way orders of magnitude abovewhat's on the website,that will become a problem.

Even today, ours says: "Starting at 100 a month,"which is true.That's in a low volume bucket,so apps with higher volumeswill end up paying more.It still creates problems for us. One is that it's not clear what the volumes arefor every customerand not everyone always readsevery line of text on your website.The others that we do have different pricing for,and this is kind of an aside, we have consumer apps and employee appsthat use our platform.We do have different pricingand they are radically different.At the end of the day just be aware.

Let's move on.

At the end of 2012, we were about 16 people.This is the breakdown in terms ofwhat the different organizations looked like.We also had grown pretty rapidlyin terms of devices.We grew from zero to 25.Now at this point we're at 335 million devicesusing the platform.It was at this time that we started really building outsome of our field teams. At the time we tried this pod approach.I believe it was something like two inside repspaired with an outside repor maybe it was one inside and one outside.I can't remember exactly what it was at the time.

Whatever it was, we just did a poor job of conveyingwhat the commission would look like to our board.It caused a lot of problems.It took us a very long time to come up withthe exact commission.All of these just created this unnecessary confusion. The good news was we had real revenue coming in.We were still trying to figure outhow to structure our sales teamand how to comp them.

Let's jump to 2013.This is the year that wereally built out our executive team.One of the things I think personally waited a little bit too long to do wasto do just that.I talked about early on ofrunning around and doing different jobs.I was still doing that. If you're the CEO it becomes clear. If you're spending time with option agreementsand doing a lot of the business development workfor the company or the marketing work, you really need to be at a higher level than that thinking long term. You need to be working withpeople who are in charge of that, setting the company goals and visionand going out in the fieldand talking to customers.

There's a lot more that you should be doingthan some of the day to day detailsthat just distract you from running the company.That's one thing I would have done earlier on.

The other thing was we did finally geta great high velocity sales model in place.I'll talk a little bit more about thatas we go along here.We also expanded our sales territories.

One other note is that we started making this transitioning.When we first started the companyit was very much focused on dev, DevOps.We started to target more and more of that IT operations personawhich is really the proper place for a productlike ours in particularwhere we focus on applications out in production.Those are the folks who manage them.

It depends on the type of product you're developing.IT operations can tend tobe a little bit used to the ways of doing things.Engineering will typically take oversome new product initiatives,mobile being a great example.Mobile is very solid within companies todayand we're just starting to see IT operationsget more and more involved. But one thing to keep in mind isthey typically have the bigger budgetsand they're actually the persona thateventually should be using our product once that IT ops team merges with that mobile team.

I'm telling you this because I'm hoping thatit somewhat translates to the target marketsthat you're all going after.It does take a different set of collateral,a different sales process,different messaging on the website.I'll talk a little bit later about some of thethings that we did well thereand some things that we didn't.

I just want to touch on this executive team concept.Pretty much all of these people were hiredmiddle of last year.I'm talking about bringing in real enterprisesales professionals, marketing professionals.

Just to give you an example, our chief revenue officer he was at Wily and Mercury back in the daywhich were two APM companies.He led sales at Splunkto a significant revenueand he did the same thing most recently at AppDynamicsSplunk is a multibillion dollar public company.I'm sure AppD will IPO this year if not next year.

You really need someone like thatwho just has a huge amount of experience in the spacethat has commanded sales teams,grew revenue to a huge level.

Now we did have an existing VP of Salesand this individual we wanted him to stay on.We actually gave him the VP of the west to control. But at the end of the day,some people who come early on into a company to grow revenue,they want to go off and do it all over againand actually that's exactly what he did.He went to another company to lead salesafter we brought in our CRO.It's a very normal occurrence.The rest of these folks have similar backgrounds.Our VP of Engineering co-foundeda $60 million infrastructure business.

I think if you're in a hot market, you're seeing some great traction,you should be able to attract the top talent out there.

I wanted to compare and contrastone other thing that I mentioned early onwhich was this transition from talking about features and storiesto problems that customers are running intoout in the marketplace,and then finally to an ROI type of sale.

This is one example slide where we talk aboutproblems that customers havedealing with their applications out in mobile.I think the more interesting slide in my mindis something like this to illustrate what I meanby really having a benefit-driven saleor talking about the ROI.These are actually the reverse of the benefits,but you can extrapolate them from here. You can see the impacts ofnot using a product like ours.What it can cost you.In some sense, a lot of customers feara lot of these things and they're running intoa lot of these problems today.You want to be able to easily illustrate those.

Another example of how to construct ROIwe have a slide like this where we show prospects.What was it like before you used our product?What happened afterwardsand how do you measure that impact?Something like this, if you're going in thereand asking for half a million dollars,it's much easier if you can say, "Well, we save you 10 FTEs.What are 10 engineers worth to you?"I'd pay half a million dollars to save10 engineer worth of time.

I think we talked a little bit about this.This was just really a summary ofsome of the things I've talked about.I did want to touch onwhat the current sales structure looks like.I mentioned we have a chief revenue officer. He's done a great job of really pulling inhis crew of experienced sales professionalsand if you bring in someone like thisthey're going to really leverage their network.I think him alone has hired something like 14 people.

What he did early onwas put some support structure in place — hired a VP of Sales in the east,a VP of Sales in the west. It gives him time to focus more.Similar to how a CEO needed to hire their lieutenants,he needed to hire his lieutenants.We also hired sales operations.We were starting to grow big enough to a point thatwe did need someone to focus on things likecommission structures, creating reports in Salesforce,integrating Salesforce with all of our other systems.It's very important.You need a lot of metrics.

You obviously don't want to always be afraidof taking action if you don't have data.I think that's one thing we probably early onwere a little bit guilty of.We kind of threw our hands up in the airand said, "Well, we don't have the data." Sometimes you just got to move on without having it.

In any case, if you are using something like Salesforceyou do need to connect that with everythingwhether it's something like Marketo or a subscription billing provider, etc.

RSM, regional sales manager inside sales rep.We actually did end up going with a team approach.What we did was we paired an outside rep and an inside rep.Each one of those was actually assigned75% worth of a sales engineer time.The nice thing about doing something like thisin our stage of the company is thattypically you'll see some conflictbetween inside reps and outside reps.

Traditionally, you'll see a dividing line in terms of: If this is a 50K deal or below maybe the inside rep will handle it,or above the outside rep will handle it. That can create a lot of frictionif there's a dividing line because you want to be able to grow these accounts over time.That kind of goes against the land and expand strategy.If I'm an inside rep I don't want to grow an accountand then lose it to the outside rep.This model gets rid of that frictionand it also means that a good inside repwill not tolerate a bad outside rep and vice versa.

We also have, there's multiple acronyms for it, BDRs, ADRs, SDRs, business development reps,sales development reps, accounts development reps.Those are more of our huntersand individuals that look at incoming leadsand try to qualify them before they're passed offto the field teams.

One other note on this,as you start expanding your sales forceyou will get kind of this clash.It's important that you maintain culture as you grow.

The sales people will tend to be more of the suitsand you'll have your engineers or the hoodies.Inevitably you'll need to pay attention to this. And that's more of an analogy, I'm not literally talking about how you dress.Although it's funny because in the Valley,I feel like I need to apologize when I wear a blazer. It's because I was at meetings earlier by the way, or I would have dressed more casual for this.

The point is just make sure you pay attention to cultureas you're growing the sales teambecause there's that analogy that they can be coin operatedor they can be more aggressivethan your engineers are used to.

In some cases you need people like that.You need people who can get out therein front of a customer and who's loudand everyone likes him or her.They're able to get shit doneand sometimes those people are different thanwhat you're used to.

I'm just nearing the end here.I just wanted to point outthis is our pricing page todayand we still have that anchoring issueeven at $100 a month.I guess the last thing I'll mention is thatwe've grown very quickly.In terms of headcount we were 16 a year ago, now we're close to 60 people.Really, we made the investmentsonce we realized that this was a huge market opportunity.

I think that a lot of people make a mistakewhere they think I can sit backand focus a little bit more. "Let's do entirely inside sales or transactional.We'll just automate everything."That's great and allbut the next person is going to go aheadand invest in the market.Get people out in the field talking to customers. And guess what?You're going to be left behind.

If you do operate in a market that's a land grab,then I suggest you go out and grab it.Today, these are all paying customersthat we've managed to getas a result of implementing a lot of this.

In summary, I think a lot of companieswill sometimes have this discussion aboutshould we go after the long tail?Should we go after the enterprise?I don't think that's the right discussion.You can't ignore developers in this day and age. Instead of having that discussion,you need to figure out what is the type of product,who are the users of that productand then focus it that way.If your target is developers, that's great.You're going to want to get corporations,large companies on board using it. I don't think you should be worrying about itif it's long tail or otherwisebecause they're always going to have side jobs and whatnot.

I mentioned most of these.One of the ones I didn't mention was thatour pricing, it was initially monthly, charged in arrears, we've actually been making a big transitionof getting paid up-front deals.This is huge for cash flow reasonsand I wouldn't recommend doing thatuntil you actually figure out your pricing.I think everyone is always iterating on pricingbut we've gotten to the pointthat we're pretty comfortable asking for a deal12 months up-front which is huge.

We closed something likeover 80% of our deals last quarter up-front. If you're building out an expensive sales forceor investing heavily in the market,it can mean the difference of many months,if not a year, in terms of runway that you haveon top of what you estimated previously. I highly recommend going ahead and doing that.

That is the end of the presentation. I would love to take questions.