Defining a Product Vision


A long long while ago, I was having a conversation with a good colleague of mine, discussing how to evolve the roadmap of an open-source project to define a vision and how to handle user expectations to an extent so developers could meet and deliver them.

Our conversation sort of stuck with me afterwards in form of the following motto:

Ask not what X can do for you. Ask what you can do with X.

I realize there are lots of “It Depends!” buried there. That’s fine. You have to factor in the relevant context though. This was coined, as I remember it, to embody the true open source and community spirit of a software platform and its users’ ability to extend and modify its capabilities as they see fit without any restrictions or hassle. The platform would continue to remain true to its roots while allowing adopters and deployers to take their deployments to the extreme edges of the world and build on top of it features and functionality that would be very different from the original core vision.

Very cool.

I want to say something different here. While I like that motto quite a lot and I think it says it all within the right context, I have been thinking about its complement. While it’s good and a true sign of power when deployers and users can take the platform and do absolutely whatever they want with it, it would be even more fantastic and awesome if the product did “everything” they wanted in the first place forcing them to keep their customizations to a minimum. This perhaps sounds like stating the obvious, but in my view, it’s the very delineating factor between failure and success. Evolution is key to success, and any platform or product that wishes to stay alive and stay relevant must redefine its core mission and vision every once in a while and must always be in pursuit of new ground to explore newer and exciting opportunities to help its community. There is no point in maintaining and working on a “beautiful, elegant, small design” that pushes all the responsibility and the liability to its community. If you find yourself often repeating the phrase “That’s not our core concern”, it’s time for you to joggle priorities and reevaluate concerns ‘cause those are what your community cares about. Beautiful design, more often than not, is secondary.

So, how do we deliver “everything”? How do we design the implementation of everything? Is it going to be a monolith? It’s going to be ugly? Big blob of mess and mud? Should it lead us to bloat? Must it be YOOOGE? Is nose-picking banned for the Philippines police?

I don’t know. You figure it out. All I know is that my new motto is:

Ask what X should do for you. Then ask what you can do with X.

Misagh Moayyed

Related Posts

CAS 6.2.0 RC3 Feature Release

...in which I present an overview of CAS 6.2.0 RC3 release.

Checking Out Pull Requests Locally

Check out GitHub pull requests as local branches using a simple bash function.

CAS 6.2.0 RC2 Feature Release

...in which I present an overview of CAS 6.2.0 RC2 release.

Apereo CAS - Authentication Handler Resolution

Learn how to resolve and select authentication handlers based on configurable and flexible filtering criteria.

CAS Vulnerability Disclosure

Disclosure of a security issue with the CAS software.

Apereo CAS - SAML2 Metadata Overrides

Learn how to manage SAML2 service provider registrations in CAS and override metadata artifacts on a per-application basis.

Apereo CAS - Managing Configuration Metadata

Learn how to manage CAS configuration and properties using Spring Boot Configuration metadata.

CAS 6.2.0 RC1 Feature Release

...in which I present an overview of CAS 6.2.0 RC1 release.

Apereo CAS - Deployment Using systemd

Fabio Martelli of Tirasa S.r.l reviews the setup required to deploy Apereo CAS as a system service using systemd.

Apereo CAS - Python Locust Load Testing

Learn to Performance Test Apereo CAS with Python Locust.