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.1.0 RC4 Feature Release

...in which I present an overview of CAS 6.1.0 RC4 release.

Apereo CAS - Multifactor Provider Selection

Learn how to configure CAS to integrate with and use multiple multifactor providers at the same time. This post also reveals a few super secret and yet open-source strategies one may use to select appropriate providers for authentication attempts, whether automatically or based on a menu.

Apereo CAS - Dockerized Hazelcast Deployments

Learn how to run CAS backed by a Hazelcast cluster in Docker containers and take advantage of the Hazelcast management center to monitor and observer cluster members.

Apereo CAS - Configuration Security w/ Jasypt

Learn how to secure CAS configuration settings and properties with Jasypt.

CAS 6.1.0 RC3 Feature Release

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

Apereo CAS - Webflow Decorations

Learn how you may decorate the Apereo CAS login webflow to inject data pieces and objects into the processing engine for display purposes, peace on earth and prosperity of all mankind, etc. Mainly, etc.

Apereo CAS - SAML2 Metadata Query Protocol

Learn how you may configure Apereo CAS to fetch and validate SAML2 metadata for service providers from InCommon's MDQ server using the metadata query protocol.

Saving Time is Time Consuming

May you live in the best of times. May you live in the startup times.

Apereo CAS 6.1.x - Credential Caching & Proxy AuthN

Learn how you may configure Apereo CAS to capture and cache the credential's password and the proxy-granting ticket in proxy authentication scenarios, pass them along to applications as regular attributes/claims. We will also be reviewing a handful of attribute release strategies that specifically affect authentication attributes, conveying metadata about the authentication event itself.

Apereo CAS 6.1.x - Attribute Repositories w/ Person Directory

An overview of CAS attribute repositories and strategies on how to fetch attributes from a variety of sources in addition to the authentication source, merge and combine attributes from said sources to ultimately release them to applications with a fair bit of caching.