The 3 things a good product manager must do!

As product managers we are juggling many different tasks. We are moving from high level to details, from customer meetings to design, from strategic discussions to bugs prioritization all in one day.

But what are the 3 most important things a good product manager must do?

1. Bring the customers to the table. Any table. I am not only talking about representing the customers in front of developers, architects, R&D managers and QA in every single meeting you have. I am talking about letting your R&D really know your customers. Your job is to make sure they understand who is your customer and what problem you are trying to solve for him. Bring them to meetings with customers, introduce them to customers usecases and issues, if you can actually let them be a customer for a day - that's awesome. I believe this is the best motivator for a developer to actually get engaged with the code he writes. You might be surprised but he can come up with productive suggestions to solve customer problems as well as letting you know you are making a mistake in the way you are designing a feature right on the starting point. 

2. Prioritize. You need to know how to prioritize the feature requests that are coming from customers, QA, support and PS against fixing bugs and improving the quality. Prioritization is done daily. It may seem like an easy task but it is probably the hardest one. You have to focus and make hard decisions and to be brave about it. Everything is important. Very important. Questions are what is MORE important? What can you leave without? What can't you leave without? Make sure you keep in mind quality and support. Don't neglect those. Once you will scale, this is the first thing you will regret and will cost you money. 

3. Be creative. We need to come up with a creative way to solve our customer problems. It should be creative in several ways. It should get the best ROI. It should be cool, simple and easy to use. It should make our customers happy. This is our job. To solve their problems in a way that will make them happy. Not necessarily in the way they want. Make sure you are not adding more and more buttons and options. Make sure you are not building an over flexible product that will make your customers miserable. You need to think hard and make some tough decisions for your customers in order to save them time and effort in making those decisions themselves.  

We have many more tasks and roles. In my opinion, these are the 3 key ones. Without those, you can't really do a great job as a product manager. Make sure you are prioritizing your tasks the way you are doing for the product features. Focus on the MOST important tasks. 

Drop your weapons

The war between developers and product goes way back. Sometimes it’s a ‘behind the scenes’ war (“these developers estimations are always tripled”, “these product people and their dreams...”), sometimes it’s face to face (you can imagine what I am talking about here).

Back in the days of waterfall, that wasn't such a big problem. Product and developers used to meet a few times in a development cycle which was a year long. In those occasions it was annoying, but it didn’t really effect the day to day work.

However, today, it is a whole new game. In agile development, developers and product interacts on a daily basis. Doing that when the war is still going on is a different story. And this one should be rewritten.

As a product owner and product manager, in the past few years I was asked many times how do I keep a good and productive relationship with development?  If I would have to answer that question in one word it will be TRUST. In an atmosphere of trust, discussions, brainstorming and working together on day to day basis becomes much more effective and fun.

How do you move on to the point of mutual trust?

Things you SHOULD do:

1. One team - the management of a project/product/release should be composed of a product manager and an R&D manager working together. As I see it, the product manager and R&D manager are the 2 CEO's of their product. They should drive it together to its success.
2. We are all in the same boat - share the same destiny, no pointing fingers. We fail together, we succeed together.
3. Go to some of the customer meetings together, R&D manager and product manager. This is the way to bring customer awareness to the table.
4. Come to discussions with data – why do you as a product manager think this feature is an important one? What did customer said that supports this assumption? Why do you as a developer think it is too risky? What is the risk? Are there any alternatives?
5. Listen, and allow yourself to be convinced – don’t come to meetings with only your agenda in mind, listen with an open mind to others.
6. Convince others – In cases you really believe you are right, convince others. Don’t just say this is what needs to be done period. Explain (preferably with data) and convince others.

Things you SHOULD NEVER do:

I understand that many times you feel you just HAVE TO say it. However, if you want to build the trust, don't. Keep it to yourselves.

As a Product manager/owner, don’t ever say:

·         But this should take an hour (not 3 days)

·         When I was a developer…

·         Its only changing a string

·         You should develop it in parallel

·         Maybe you should try extreme programming?

As a Developer don’t ever say:

·         We can never do that

·         It’s crazy

·         This feature is too big

·         What did you smoke? 

Yes, it won't be easy. Yes, you need the right people to make it happen. But if they will put their heart into it, after a while, trust will be built between product and developers. I won't lie to you and say that the tension will disappear, I won't say there will be no arguments. I think there better be some. But trust keeps us productive and maintain a positive and professional atmosphere. It might take time, building trust is not something that will happen in a day. You need to work on it and be patient, but it is totally worth it.  So, drop your weapons, and start building the trust!

Keep it simple, it may lead to a love story!

We need to keep our products simple. Simple is better. Simple is easier to use. Simple is easier to change and adjust. But most importantly, people just LOVE it when it is simple.

I am not saying that we should build a dummy product that only does simple tasks. I am saying we need to think hard how to answer the usecases in a simple way. And we need to carefully choose the usecases we want to tackle.

“The road to hell is paved with good intentions” – no one wants to end up with a product that feels like hell. We need to be aware of complication that will eventually make our customers miserable. By trying to answer ALL usecases of ALL users, we tend to add more and more tweaks to the feature. One more button, one more option, one more step to the wizard. Sentences I hear a lot are “but this way we will also gain usecase #3”, “But there was a customer that we met that wanted to have it this way” etc…

We must remember - every time we are giving our customer more than one option we are making him choose. Every more step in the wizard is more work for him. Every time the customer needs to try and figure out why something just happened in our product, or what will happen if he will push this button – he is wasting his valuable time.

Think of yourselves when you are using your day to day products. What is the one thing that really makes you happy? That delights you? Simplicity! Whenever we are using a product that we do not need to think in order to use – we are happy. Whenever it does exactly what we expected and we didn’t need to give it a second thought – we are thrilled. We want it to be easy, simple, and predictable. Will we ‘forgive’ the product for not having one more complicated feature? In my opinion, if we love it, we will forgive many things. That’s what people do when they are in love.

But, what should I do if there is a super important customer who really need the complicated scenario?  you can have a very simple, easy to use product, which allows also complicated scenario’s but there are never interfering with the main simple usecases. The advanced user will be able to use them but the other ones won’t pay the price for it. I still recommend to avoid it whenever possible, but this is a way to keep your product delightful while answering an important user usecase.

We should also consider code simplicity. I know you will say it is the R&D job, but we have a role here too. Complicated code will always come back to haunt us. It will probably produce many bugs, will be hard to change and adjust and will be hard to maintain. All of these cost time and money, which we could have spent on some new, cool and simple features. When we are keeping the code simple, we are investing in the future. We are investing in quality. Quality is crucial for our customers to LOVE our product.

There is a price here. We might not answer all of our customer’s usecases. We need to make peace with it. We need to accept that in the name of simplicity, we might be giving up flexibility. We are not going to make all dreams come true. It is OK. It is our job.

I am more than aware of the pressure. I am living it. Customer requests puts a lot of pressure on the product and sometimes on the management to get a new feature. We have to keep our eyes on our goal. We want customers to LOVE our product. We want it to be as simple and predictable as possible, with high quality. We will add a feature to our system as long as it doesn't ruin it. When we are ‘sacrificing’ a feature – we are doing it for a good cause. Keeping our product simple. Making our customers fall in love with it.

Is it good enough?

How many times do we ask ourselves this question? what is good enough? others might call it - what is the minimum? what is 'potentially shippable'?

The thing is, that if you put 10 people in the room and ask them this question, you will get 10 different answers. Its all about perception. Usually (but not always), developers will be fine with releasing a product with 'half' features while UX people will think it is crazy. I believe that in order to be able to answer this question, you should first as yourself these ones:

1. If I am releasing this 'half' feature, will that feel like a bug or a missing functionality?
2. Will the customers be more happy with the part they got then frustrated with the missing part?
3. Will I be able to get some valuable feedback from the field on if/how to continue developing this feature once I release this 'half' feature?

You need to answer yourself these questions honestly and be willing to let go on the 'complete feature' attitude that used to be much more relevant in the days of waterfall when we released a version once a year and not once a month.

The way to accomplish just that is to develop the product in the new 'layers'. You deliver the 'minimum must' of each 'must' feature and you incrementally improve those in the next versions. You might find out that you will stop developing some of them as they are not that useful to customers as you originally thought. That is the beauty of it. You are making sure that developers are always working on the most important stuff.

One more thing to remember. The answers to the questions above will probably be affected from the maturity of the market. Let me try and explain: imagine I would come to people 60 years ago and suggest them a machine that will wash their dishes. This machine will have an on/off switch, a place to fill in water and soap (no water pipe), and a designated bucket for the dirty water which you will have to take out and empty at the end. But hey, you wont need to wash them your self ;) I am guessing people would buy it (at least some). However, if I suggest them the same today - people will kick me out of the room. This is what I mean when I am talking about maturity. You have to be realistic and look at the market.

But before all the tough questions, the first step is to break a big feature into small pieces. I mean, the smallest ones. Then, group several of the pieces as a phase/step of a shippable part of the feature. Remember, the way to do it is to answer the questions above. Make sure you are not grouping ALL of the pieces together, in most cases, you shouldn't.

Lets look at some examples:

1. New 'campaigns' management grid
1. Display grid with the columns: Name, Conversion rate, ROI, Cost
2. Create campaign
3. Delete campaign
4. Copy campaign
5. Edit campaign
6. Pause campaign
7. Sort table
8. Filter table
9. Select columns
10. Add columns: Statistics, Creation date, Start date, End Date
11. View Ads

How would you break it? let me try and do it:

1. Phase 1:
1. Display grid with the columns: Name, Conversion rate, ROI, Cost
2. Create campaign
3. Delete campaign
2. Phase 2:
1. Edit campaign
2. Pause campaign
3. Phase 3:
1. View Ads
2. Sort table
3. Filter table
4. Phase 4:
1. Select columns
2. Add columns: Statistics, Creation date, Start date, End Date
1. Copy campaign

For each and every phase I will ask myself the three questions above. If I am not happy with the answers I get, I will adjust it again. This is the process of splitting features to deliveries. Always compare the next phase importance against another feature's phase. Do not look at it as one block. Make sure your priorities are cross features and be honest.

Keep in mind that you may never get to develop phase 4. That's fine. It means that you had something more important to develop. It means that you are always developing the most important thing and that is what you wanted to accomplish. Everything is important, the real question is what is MORE important then what. When you have a tough priority question - ask yourself what you can leave without.

The question 'is it good enough?' should be always answered with respect to:

1. The answers to the questions above
2. The importance of other stories in your backlog

I believe this is the way to really utilize the agile development to the benefit of the customer. Good luck!