Memoirs of a Product Lead in training

Being a dev for a year plus, converting story features into beautiful python code, I grew more interested in the what and why of the products and tools I help build, focusing less on the how (which is what I currently do). I believe there is that point where you care more about how users interact with the tools you build, how they feel when using them and if that same product is actually solving their needs. You begin to ponder on the necessity of the features you build out and wonder about the market value of that same product. At this point you begin to think about how business needs should translate into product features that are both usable and have a great market value. I did get to this point and became more interested in being able to greatly influence the direction of a product rather than just optimizing a feature. My chance did come at the start of this year 2017 (yay!!! to new year resolutions) to explore what my immediate product mentor (Ebun Omoni) would call the Wild Wild West of Product.

Fun fact: He calls it so because of the way products tend to change direction in terms of scope and priority. I know, I have felt this too.

“It’s the wild west mostly because the world of problems and business needs can sometimes be chaotic and, when working toward delivering value in the form of product, the way you figure out what’s the right to work on, at the right time, and w/the right amount of effort is not always straight forward…” — Ebun Omoni

At the start of my product journey, I was thrown around for a bit before I got settled with the chance to build a product from the ground up. I was psyched at the opportunity to be a major part of building this product through its different phases, so with my head held up high and my pedal to the metal, I engaged onwards.

I’m two months into being a product lead and while it’s fun and engaging, I have learnt some important lessons along the way but before I share my lessons, I want to emphasize that having strong INTEREST in product development is really important before starting out this journey because it’s what will keep you when the going gets tough. Now onward with my lessons!!

Keep up the communication always!!!

Communication in all it forms, be it slack conversations, sending out emails, video calls or in person meetings, is super important to being a successful product lead. Part of your day to day being a product lead will be updating your stakeholders about the progress of the product being built and keeping the development work aligned with the vision of the product by constantly providing feedback from stakeholders and users.

Personally, in trying to keep up the communication around the product I’m product leading, I find myself mastering the act of summarizing long meetings for the benefit of all stakeholders, developers and other interested parties. As the product lead, you will be the main point person for the product you are leading so it’s important that your communication game is as clear and as succinct as possible.

Early and often releases help show progress while being a form of communication in its own way.

Pictures are worth a thousand words and sometimes the best way to show progress and get feedback is having a place where stakeholders could go and use the product being built.

An advantage of this is that it will help build the trust between you and your stakeholders as they will be able to see that you are delivering on what you would have already promised you will deliver. Also in this day and age of agile development, getting feedback early enough is both critical and helpful. You don’t want to have built something so large only to be told that you have to redo the whole thing.

Having an Eye for Design

Well I’m not talking about being Pablo Picasso at this stage but take a look at the image below (credit to my product mentor for showing us this image)

As a product lead, you should begin getting comfortable with thinking in terms of user experience. Here are some beautiful quotes about products and UX.

If the user can’t use it, it doesn’t work. — Susan Dray
“If we want users to like our software we should design it to behave like a likeable person: respectful, generous and helpful.” — Alan Cooper
“There’s a big difference between making a simple product & making a product simple.” — Des Traynor, Warmgum 2014
“A beautiful product that doesn’t work very well is ugly.” — Jony Ive

excerpts from http://uxdesignweekly.com/ux-resources/ux-quotes/

Always break down stories into smaller chunks

I will say I did learn this lesson the hard way. With only 2 months being a product lead, here is my story below.

After discussions with stakeholders, I had built out the product road map and sketched out the designs that led up to an MVP. I was particularly proud of this accomplishment as I felt I had this product thing in the bag. I scoped out my large chunks of stories into features for the dev team and work began on them.

On a subsequent meeting with my main stakeholder, the timeline to releasing the MVP was brought forward and I became panicky because looking at the set of features I had scoped out to be delivered, I didn’t feel that confident anymore.

I did get help in reducing the scope of the product (thank you Roberto Goizueta and Andela Technology dept) and while we are still on track to delivering on this new timeline, my major takeaway here is never let those chunks be the final break down of the work to be done the first time around. Look again - there is always some more fat to be cut out.

Wants are not Needs!!!

It’s worth mentioning here that you should always clarify with your stakeholders, the needs and the wants of a product as the wants tend to form the fat of a story’s acceptance criteria.

Needs — without these stuffs, our product is unusable (e.g. Imagine WhatsApp without the ability to send text)
Wants — these are nice to have and the lack of, doesn’t impact the usability of the product (e.g WhatsApp new status update feature)

In object-oriented programming, there is the SOLID principle with the “S” being “Single Responsibility”. Borrowing this idea into creating feature stories for your product on your PM tool, you will want to make sure that the goal of a story is to accomplish a single critical need of the product.

These are my lessons from my crazy adventure navigating the wild wild west of products and I’m sure to learn more as I continue my journey with products.

Cheers!!!

Show your support

Clapping shows how much you appreciated Olufunmilade’s story.