I was always very impressed by their office on the end of New Montgomery Street in the heart of Downtown San Francisco. You could see some very swaggy kitchens and open office space through their floor to ceiling windows on the ground floor. I was jealous for some of the employees who worked there.

Maybe this is ad hominem, but it seems to me they must've raised a lot of money to prioritize that kind of setting, likely in the guise of recruiting. Crunchbase lists them as having raised $251.2M and their last round being debt financing.

If this is a down-round acquisition with most of the employees gaining very little I wonder if this is a lesson to founders to be more cost-effective and raise less money.

There were a bunch of startups right there. From the fact that we rented commercial space there (like a minute's walk away), I know that if they leased before 2012 it was going to be a sweet deal. I don't remember any of the numbers now but I recall that if I could get that deal today I'd take it in a heartbeat, even if just CPI adjusted. I think we had just under 10k sq. ft.

> One clear problem for Optimizely in this space is that experience optimization became a function of marketing departments through out the years but for a while they were positioning themselves as a developer tool. This go-to-market strategy opened a lot of opportunities for other players who saw a bigger market when selling the same type of solution to Marketing Departments.

I can't speak for all industries, but for the ones I'm familiar with, marketing is always the product owner of websites. With two practical implications being

1. The entire website costs (development + software vendors) ultimately get booked against their budget, so they have the true purchasing authority for pretty much all the website tech that isn't centrally mandated/controlled

2. Website projects (including budget and requirements planning) tend to start in marketing loooonnnggg before a tech resource gets brought in. So developer awareness/familiarity ends up moot, since there's too much incremental effort and cost involved for it to be easily get buy-in and added to the plan at this stage.

It makes a ton of sense to target your solution at them instead of developers. They may not be able to use your product well or do the implementation, but they're the ones with the purchasing authority and ability to ensure the budget accounts for it. And can add it into the project requirements far earlier in the planning stage than when tech resources get involved.

Google Optimize & VWO hurt them. Free, or low price, low friction won at scale with smaller teams running 1-2 experiments or low level personalization. Everyone I know who's going to high volume testing is either on a hosted CMS that has this baked into their offering or JAMStack.

No one I know has deployed Optimizely since 15/16.

Thats the issue. They start at $50k. No startup can afford that, so we build our own or use google optimize. I've been at multiple startups that have scaled to millions of users and Optimizely could have been a player if they had a self service budget option. Need to get in early like other saas/cloud providers because the cost of switching becomes to high as the business scales. Imagine if AWS didn't have self service option and you had to go through a sales process with min commits. It would have failed.

Optimizely's pricing makes no sense for small teams but VWO and Optimize cannot compete on features that start to become very useful as your experimentation and personalization efforts increase.

Any roll-your-own experimentation platforms take considerable resources to make accessible to those in the organization interested in using it (product, marketing, etc.)

In my experience, I agree the core functionality (variant management, remote config, etc.) is relatively small amount of effort compared to the interfaces to make it accessible to those non-technical orgs, like you mention.

However, we found that those interfaces only allow very limited, shallow tests and you very quickly outgrow them as an organization. In other words, once you reach diminishing returns on button color and header text optimizations, you start wanting to test deeper UI experiences and complicated user flows. At that point, you have to involve engineering anyway.

When an organization has engineers who are motivated by business metrics, they have no problem implementing shallow tests (like button colors) while working on tests of the deeper UI experiences as well. And at that point, the non-technical interfaces have little value.

I wasn't really talking towards the WYSIWYG editors. Those are trash on all platforms and fall apart quickly for all but the most simple tests.

Metric + page management, results analysis, segmentation, etc. all work better in Optimizely than they do in other platforms.

Optimize is not an incumbent but a challenger. Google Optimize came out years after Optimizely and is less featured and built by a smaller team. The main benefit to Optimize is that it's cheap.

I didn't mean to say that Optimize as a tool is an incumbent. What I meant is that Google and Adobe as companies are incumbents.