ruff

Ha, if you think that was bad, you should have been there when it was just Entourage ;).

I'd bet $100M on IFTTT if I had it. They've got an amazing ecosystem of often proprietary devices and services feeding event information into them.

v1 is rules by end-users—v10 intelligence by the system.

What if they could take that data and create concepts around the identity of people using those devices, where they are at certain times, what they're doing, etc. etc. Turn all that data around and broker it back to services/devices, making each of the providers that much more powerful but dependent upon IFTTT. It's super-charging the internet of things in a way that perhaps only Google (with Google Now) seems to be thinking.

Maybe different now—back then, nearly everyone only had a single Exchange account. We looked at supporting both WebDAV and EWS. The result would have introduced by confusing UX but also reduce reliability of both solutions (adds a lot of testing complexity). Instead, we did a release of Entourage with WebDAV (a horrible protocol that Exchange barely ever supported) and a free update with just EWS support (also rough initially, but much better designed and fuller-featured).

When we got to building Outlook, we decided to look forward—Cocoa and EWS only, building a strong base so that future releases could be far more capable. When I started on Entourage, the team was executing on a strategy to shove Exchange capability into a consumer-oriented app. It was shaky from the start, there were so many problems and customer complaints. I gradually learned as a PM that often a more impactful but riskier product strategy is to go big—instead of fixing 50 small issues a week at a time, fix 1 big issue that takes a year but renders the 50 irrelevant.

I was the PM who led Outlook for Mac 2011; so I know many, many of those tricks. We rebuilt the thing in Cocoa with an entirely new Exchange client codebase—it was a beast of a project done in a fairly short period of time.

For better or worse, there were a lot of edges we didn't get a chance to smooth out by the ship date though I believe we made reasonably solid trade-off calls based on the team and deadlines we had. Updating the Export feature was one of those trade-offs (it's just not a super frequent user activity); that part of Outlook leveraged code from the much-despised Microsoft Entourage. The app was far from as full-featured as some users wanted (especially Win Outlook switchers) BUT did make enough progress to avoid the backlash of other "rewrites" out there (e.g. Apple Final Cut Pro X).

Little insider history: we did a lot to try and make sure data didn't get locked-in... we really wanted a place where, even if your app crashed, you could always get the data out of the app. During development, we even had builds where the entire underlying database was exposed as XML docs (one per item in your db). We couldn't get the perf we wanted out of that system. We ended-up with Outlook 2011's database which still bites folks from time to time but has a lot more "recoverability" than previous products such as Entourage (where it users often cited being locked-out of their database).

FYI

If you drag one or more e-mail message out of Outlook for Mac, it creates .eml files. These are just RFC2822 MIME source with a file extension—almost any mail client out there can read them. If you drag an entire folder out, it creates a .mbox file. This is also a standard that many mail clients can read/import (Mail.app included).

Probably not something I can share (sorry); just, really, good management isn't often as much about "command as control" as it is steering a lot of smart, opinionated people who often disagree.

You're completely right on the growth aspect. If you're working somewhere with a founder and their not growing in that way while the company is, I can see nothing but headaches. The original link essentially calls this out... what you did at 5 people doesn't work at 50, which doesn't work at 150, and on. You gotta learn and adjust; as it scales up, the folks who help move beyond the Founder and into a trusted group.

You're missing the point. At some time, a company has figured out at least one way to succeed. At that time, you're going to grow extremely rapidly and take all sorts of ways the company does things, break them down into elements, and optimize to accelerate that growth. The "management team" are often the ones who drive that optimization. Someone who understands engineering is going to lead building software at scale. Someone who understands sales is going to scale out your sales. And so forth. Founders often lead this and see across all spectrums.

FWIW, I worked at MSFT and had opportunities with both Gates and Ballmer. I can absolutely ensure you management teams existed at the company. Hell, Microsoft is made of layers upon layers of management teams. A young, bright-eyed version of myself thought this was inefficient (and it was to some extent). But I got a chance once to ask Ballmer what a typical week was like for him--holy hell, managing an organization of 90k+ employees is not a challenge that many of us are made out for.

This is interesting—as someone who is part of a "management team" at a company that has grown rapidly from startup to perhaps a post-startup stage, there is some truth to this.

There's a giant void of advice out there for folks who are making this transition. It's awkward and really challenging; like hitting puberty for your company (I like to say we've got braces right now). HN and publications focus a lot on startups. Business education and literature is heavily focused on "management" in the sense of Fortune 500 like worlds (I've been in that world as well). My sense is those two appeal to much wider, paying audiences where much smaller sets of people actually make these jumps. There's very little advice/tips/thoughts about how you steer your company as you get more customers (e.g. how to manage early customers who got more attention as you were proving your product vs. later on when the cost of that attention might be a challenge), hire a lot of employees (training, compensation models, etc.), build out teams (trade-offs of various structures, ability to repeat and scale), etc. This stuff is hard and unless you're growing at such a rate you can ignore it until much later on, you have to deal with it.

Does anyone out there have a collection of posts/tidbits/advice for others who have actually managed through these transitions? The linked post talks about trial-and-error. I'd love to read about what worked and what didn't for others.

BTW, another approach is eventually tackle a vertical... perhaps you'll end-up being the #1 CRM app for small practice attorneys, dentists, accountants, etc... you can potentially carve out a niche there, give yourself more focus on whom you want to build for and what their problems are, and find venues for better addressing those markets. I know several folks who started out thinking "broad", received limited but helpful initial adoption, talked to their customers and saw patterns of the types that seemed to have the biggest unmet needs and were actively seeking new ideas/solutions. Then you start to double down.

Small thing—but not sure I'd buy a product from a company called "Dangerous Apps"

It's been a while since I've used Goldmine, ACT, or any of the more SMB focused CRM apps but it's definitely not clear why I'd choose CRM Fly vs those products. i'd emphasize simplicity and ease of use—there are a lot of folks out there who benefit from sales tracking tools who simply don't need everything out there.

Would, however, suggest things like XL exports and perhaps consider SaaS opportunities or partnerships around things like invoice printing/automation. If your approach is "simple, easy, helpful" (cause the other guys are complicated bloatware) then think how you can do this end-to-end for whomever you are designing/building for.

A very tough problem to solve: you organize by customer and you start to get requirements driven by particular customers, making your more of a custom dev shop that can't scale the business. You organize by engineering team and you become a project manager with less visibility into customer needs. You organize by Product, intersecting between projects and customers and you end-up with lots of ownership questions and gaming by PMs (strong PMs often will circumvent others to get satisfy their customer and/or project deadlines).

I've settled on the same conclusion as I've grown our team (and tried out all of these pivots along the way)... focus on the product and scaling the business out. Settle cross-ownership disputes by trying to clarify who makes the decision. Reflect regularly and adjust accordingly.