We've learned a lot in the last 2+ years building software at Telligent. One of the biggest lessons we've learned is one we didn't really anticipate: a shift from caring less about the underlying technology to how our software solves the user's problem. It's a subtle change, but as an ISV this is probably one of the bigger "maturing" steps a software organization has to go through. You can tell when an ISV hasn't made this transition yet: the literature and announcements about their releases focus 100% on the underlying technology instead of how the software solves a particular set of problems for the people that use it.
If you had asked me 2 years ago about what we wanted Community Server to become the answer I would have, and likely had, given would be something involving: Provider Design Pattern, Server Controls, SQL Server, etc. In other words, I'd tell you about all the cool technology we were using and how we were using it. Today the answer is very different – in fact internally we judge our own success when customers use our software because of the problems it solves, not because of the technology it is built with.
For example, have you ever bought a car because of where the steel was made or because of the brand of the engine? A few people care about these things, but most people care more about: does the car drive good, are the seats comfortable, etc. Make no mistake about it: as developers we're .NET through-and-through, but we have yet to have a customer choose our solutions simply because we wrote "good" code; although we still like to think we do that too 🙂
Today we're in the midst of building 5 new products and our philosophy is: (1) build it as quickly as we can (2) start using it as soon as possible (3) make it simple. Two years ago the phlosophy would have been: make it scalable, make it extensible, etc. Bottom line – If we had started these new projects 2 years ago I don't think they would ever be completed. Now I get worried when I sit in a design review and hear someone say, "we want to make it scalable and extensible". To me that translates to: "We don't know or understand our customer or the problems we are trying to solve, so we'll try to do everything in v1.0."
Are we doing some cool things with the underlying technology? Absolutely! But first and foremost we're going to build software that solves the problems. One of our new products is a CRM system which we started using internally about 4 weeks ago. Our goals today are things like, "the user doesn't have to take their hands off the keyboard to create a case" or "creating a new contact should have no more than 2 required fields". We're not using the provider design pattern, we're not supporting multiple databases, we're using dynamic SQL, we're doing tons of code generation – in other words, we're building software that solves the problems first. We'll solve those other problems too, but we'll solve them later as the software evolves and matures.
