On Product vs. Services…

Something I’ve always struggled with a bit in software development: when you build software for a specific use case, where is the line between building a software platform and evangelizing/enforcing a method or philosophy of doing something?

A long time ago, my team was asked to build a “project management system” for our company. Shortly into building it, I realized that we were having to make non-software decisions. We were having to decide what a goal or milestone was, and how it worked, etc. We were sort of having to design a project management process, and then we were building a software platform to support that process we designed. (Also a problem: the team had an average age of, like, 25, so there wasn’t a whole lot of wisdom and experience to spare….)

With more generic system – like an all-purpose, non-opinionated CMS for example – you’re dealing with such broad concepts that you might not have to make these decisions. You’re building such foundational pillars that you’re leaving it up to the user to decide how to use them.

As use cases narrow and you start zeroing in on specific scenarios, you start unavoidably encroaching on human process. You start making decisions that will affect how humans do things. How do you know you’re making the right ones? And at what point does adopting your software platform mean your customer will have to fundamentally change how their company works? And will that change be for the better?

Honestly, I don’t know if there are any hard and fast rules here. Hopefully, you have a broad-enough base of customers that you can see when you cross this line, and if you’re on the right side of custom and practice. Additionally, you can always have an eye towards flexibility and alternate use cases… but not too much, because you can get too flexible – your system can devolve into mush, if you’re not careful. (What’s the quote? “He who stands for everything, stands for nothing…”)

I’m seeing the results of these decisions at Staffbase. I’m impressed with the flexibility of the product, but there are aspects of it that simply reflect opinions of how to do things. To be clear, they’re well-informed opinions, and our customers love us, so the answers must make most of them happy.

We’re talking a lot about where the line is between software and process. Are we just providing a platform, or do we need to coach our users into changing (fixing?) their process, both to match our opinions, and to just be better. We have thousands of years of internal comms experience here – we do know a thing or two.

At some level, this is terrifying. I don’t want to tell people how to do things, but as a vendor, we have to stand for something. Here’s to hoping we stand for the right things…