3 Things to Avoid as a New Product Leader

I lead a Product Development team for a company Delivery Dudes. Our team consists of a small group of talented software engineers, a designer, and myself. We have an amazing time building products for our customers, our drivers, and our restaurants. What does this mean? Lots of products and features. Being a small team, we have to be very strategic with every product decision we make. Roadmaps get updated, priorities change on a dime and we need to be agile.

The following article is a collection of lessons I’ve learned the hard way. I hope that this helps you approach product development a bit differently.

1. Designing and Building in a Silo

Talk to your users — make it a part of your process. Over communication during the product development process never happens. Spend the time up front to better understand the problem you are solving and you‘ll end up ROI positive. One effective way to make sure you are not designing and building in a silo is by conducting user interviews.

2. Operating as a Feature Factory

A solid Product Leader knows to focus on outcome, not output. If you are part of a team who blindly ships features, you are setting yourself up for failure. Build, measure, and iterate. Do the homework up front to properly scope before you touch code. Praising shipping tends to happen but is not correct. Instead, praise the results of your product or feature. Define those results up front using a framework like OKR’s (objectives and key results ) to ship work that affects the business. Are you working on increasing retention? Increasing conversion? Have that conversation early and use it as a north star for your work.

3. Solving Customer Problems with Features and Assumptions

Tech is fun! Ideas get designed, features get built, and if they don’t work out then it was something wrong with the implementation, right? Wrong. Far too often we start in the feature building state instead of the problem identifying state. A surefire way to get frustrated is to ask executives or colleagues what feature should be built.

“I read that company X released Y feature and their [name of metric] went up 400%! Let’s get building!”

If resources are wasted, it is not the executives or colleagues fault, but rather the product leaders fault. A true product leader knows what is best for the user and reverts the conversation back to the problem solving space.

Thanks for Reading my First Article!

Also thank you to Marty Cagan, author of Inspired —this book had a large influence on my actions as a product leader and is an amazing read.

Follow me on Twitter, Instagram, or drop me a line at [email protected]

I am always looking to network / meet new people.