Product Management with a J. Cole Mentality
This post is in relation to building software products, with some Worldstar Hip Hop sightings & other pop culture references. If that mix interests you, read on.
Features are an interesting thing. So generally applicable to various industries and fields, they come with extra baggage like a Kardashian staying in [insert anywhere but Paris here] for the weekend. A quick Google search produces the following definition:
“a distinctive attribute or aspect of something.”
Here’s why that definition does not scratch the surface in the world of software development:
Features are eight-legged beasts.
Early on in my quest to break into the “tech” side of tech, I worked at a few startups and did some freelancing. Grateful for all of my opportunities, I was able to work across mobile development, user experience design, and product management. As part of a daily workflow, I would receive requests from higher-ups for new features, and anyone familiar with the storyline at an early-stage startup knows it sounds something like the following:
- “xyz feature would work well with our abc, improving the user’s experience”
- “how long would it take to implement xyz”
- “It would be great if you could also do [insert letters here] while on xyz”
Looks harmless, right?
(*)Trademark pending, I am in a close race for it. Looks like I am going to win according the media. We’ll see.
What I learned, after going through the above process a few times is that both fully-fledged apps and their features are ecosystems that need to be fostered and cultivated. Therefore, my definition of a feature in the world of development is even shorter than Google’s:
A feature is an ecosystem within an ecosystem
Working on a feature does not stop when it’s “pretty much done,” realistically it has just begun. And if you compromise this premise, you are compromising the stability and, somewhere along the line, security of your product.
And if you have many feature requests, it becomes a common occurence. There were instances of prioritizing building xyz and then leaving the rest as sort of secondary tasks, such as making sure this newly introduced ecosystem did not interfere with the equilibrium of existing ecosystems, was built with scalability & flexibility in mind, and did not take time away from ensuring that existing ecosystems were built as robustely to handle a new guy entering the fold. I learned not to let these instances become common occurrences.
Instead of continuing the complying, I channeled J. Cole:
But on a serious note, when you have a lot to do in very little time — as is always the case in startup land — sometimes you just have to say no. I thought this was a bit harsh, but it’s beyond your control if a co-worker takes it personally. That being said, there are different ways to say no — I found most success when it was coupled with a short explanation:
That does sound interesting. We have structured our sprints to prioritize work on the core components of the app, testing them individually and collectively, before moving on to adding any new type of functionality. We can add this to the backlog to discuss upon completion of the sprints centered on our core components.
As someone in charge of making sure no one’s time is wasted, giving an answer similar to the above conveys that you care about what they’re proposing, while saying no to doing it imminently and leaving the door open to think through the idea at a later date. That discussion could go similarly to The Ringer staff debating the validity of the aforementioned rapper (I’m siding with Justin Charity if this post wasn’t obvious).
Further Reading & Viewing
For those interested in keeping in touch, feel free to follow me on here & Twitter @Rizk_Taker or shoot me an email at firstname.lastname@example.org.