blog Product Management

As a product manager, what are some anecdotes you find yourself using often?

“Don’t think about how to make your product better. Think about how you can make a life of your customer easier”

In my previous job, I would often be tasked with researching how to plug holes in the 10-year old legacy product. As with many legacy products – it was surviving not because it was good, but because the competition hasn’t caught up yet. One of our main competitors was making a really good progress on catching up and we were scrambling to find and build a feature that would slow down customer leakage.

Instead of thinking of how to make the product better I went to the sales team and asked them what would be the lowest hanging fruit to address with our customers. They were, at the time, under a huge pressure from one of the large accounts threatening to leave. I asked for a “Christmas List” – a list of wants (not features) that in an ideal world this particular client would want to have. What would make their life as our client easier?

One of the items somewhere in the middle of the list was “ease of inventory import from third-party vendors into your system”. Apparently, someone within any large client spent anywhere from 4 to 8 hours per week manually copy-pasting large orders (hundreds of SKUs) from vendors sales orders into our system. I’ll leave it to your imagination to think about all kinds of input errors they were dealing with. But it was literally, copy a line – paste a line. Repeat 100+ times over. Check for errors – manually.

I’ve looked into the problem and within a month we had a solution ready. It was not directly built into the product, which means customers could use it on any other computer, not just where our product was installed. It completely eliminated the need to manually enter anything at all. Instead of 4 to 8 hours, it took 4 to 5 clicks to automagically import each order into the system.

Not only it saved this particular customer, but that was also impressed with the effectiveness of the solution, the speed of the solution’s delivery and with saving on average 20 – 24 hours of one of manager’s time. It allowed the company to promote the “champion customer” program where certain customers would get access to early-stage products I was developing and provide their feedback.

While solution itself was free to our customers compared to the amount of money saved by retention it was definitely a revenue-positive discovery.

blog Product Management

What are the pros/cons of having a product owner?

It depends on processes implemented at your organization.

If your organization has classic Scrum (or Scaled Agile Framework – SAF) Product Owner role – it boils down to a having a single point of reference when it comes to product development. Product Owner (PO) is a face, heart and a brain of the product team. Business goes to PO to learn deliverables, timelines and resource allocation as PO is responsible for product backlog (and parts of program backlog in SAF). Speaking from experience being a PO – it’s a high visibility role that comes with some perks (you get to talk and influence some highly placed decision makers that would not be accessible in an old-fashion environment).

What I also found helpful while being in PO role is to sometimes take “one against all” stance to present a solution for a business requirement to scrum team and have them poke holes in it and offer better approaches. This is both a great way to engage team (especially a newly formed team) in finding the best solution given current requirements and a good team-building exercise. Without it, I have found the team to be less proactive and not as cohesive (everyone would offer and defend their own solution thus fragmenting overall approach).

It does, however, come with the same high-level responsibility and in case of failure it will be way more prominent (again, because you are exposed to high-level decision makers). It also presents business with a single point of failure in case PO becomes unavailable (time off, sickness, moving on to another job, etc). Immediately a product expertise, leadership, and vision become unavailable and the team loses focus without direction. This is usually remedied by delegating and training other team members to act as substitute/replacement when PO is unavailable. Personally, I found it very hard to schedule any significant vacation time because my presence was required daily to resolve issues (especially with high-level decision makers).

If your organization is not “agile enough” – i.e. has not progressed to implement agile processes far enough for PO to fully assume all responsibilities (you can read about them all here and here) then product owner(s) act more in either business analyst capacity or team lead capacity, depending on which responsibility the given team is short on. In several cases, while being PO I was acting strictly as team manager (without being subject matter expert and having product vision) or Business Analyst (without leadership responsibilities), sometimes at the same time while acting as PO on 2 different teams. In such cases, PO is just a moniker for someone who doesn’t have high enough rank in old matrix organization but who assumes responsibilities missing from the team. The “pro” here is that PO plugs in organizational holes and takes responsibilities that otherwise would have to be taken by higher-ups and usually managed lousy due to lack of interest from said higher-ups.

The cons are pretty obvious – you’re not formally holding any title and you can’t really push your agenda since you almost always negotiate from a position of weakness (being a lower rank than almost anyone else you need a commitment from).

Additionally, PO ends up checking all decision (even small ones) with management (usually not readily available) which tends to drag product development forever. In this case having a PO actually introduces one more middleman between the team and decision makers.

It’s also high risk/high reward kind of proposition because you’re low enough on matrix ladder to be easily sacrificed if your manager feels you’re failing and wants to protect himself but if you perform well you get a lot of respect from people way above your manager (and your management will cut you a lot of slack while you’re in good graces with their superiors).

And, of course, if PO is removed from their role (for whatever reason – moving on or moved out) the product/team will be back to square one – with the same gaps/holes in the structure.

blog Product Management

What does a product manager do?

When planning a product range for what are the most important considerations a product manager will take into account?

Product manager, as the name implies, is one who “manages” the “product”.

As you can see I put quotes around two words – “manage” and “product”. The reason is you need to be very careful when defining those two. Some companies, when referring to product manager, assume it’s the same role as Project Manager, with a single caveat of managing projects for a single product. In a classic sense of Product Management – this isn’t entirely correct.

A Product Manager is, in a way, a CEO of a particular product. A product manager has to be involved in all aspects of developing a product. Since I am most familiar with software products please assume the rest of this answer is related to software products only. I am not speaking of any other products since I don’t have any experience managing those.

A Product Manager is a person responsible for all aspects of his or her product – from roadmap to choosing the technology and building a team that develops the product, to marketing to sales. In the ideal world the Product Manager is working across all departments in the company towards success of his product.

For example – I have an idea of a certain product, I go to C-level executives to get their blessings to continue, get the resources and then go to line/department managers to procure said resources. In this scenario I have to sell the idea to C-office and VPs, show them where ROI will be coming from, show them projections on what it’s going to cost, etc. In other words – you have to present the business plan for your product – same way you have to have a business plan when opening your own business. So you do your homework, your marketing research, your estimates, see what the competition is doing, how fast are they going to catch up once you release your product to the market, and so on. Once you’ve sold Cs and VPs on your idea – you have to go and negotiate your product into other people’s agendas (unless you’re hiring a brand new team). In many cases you will need to allocate resources from existing teams, rearranging their existing plans/sprints/scopes/roadmaps. This is in addition to whatever else you’re working on at the moment. You may get a chance to offload some of your stuff to a colleague because your product seem very promising. In most cases, however, you get to add that product’s responsibility to everything else you already doing.

In a real world it’s not all that well defined. Depending on the company and structure – you may be running a few projects here, help with a process there and someone from C- or VP-level hands you down some stuff that you now are responsible for. So it all really depends on the particular company structure, their way of doing business, etc.

So when you’re planning a product range – you have to take into account common and different elements of your products, make sure you’re driving your customers to the product in range that both solves their problems to the fullest extend and maximizes your ROI. I’ve seen some product lines where the offer was so complex that potential customers gave up on analyzing the feature set of each product in line up and simply signed up for either the cheapest (which wasn’t doing all they needed and, therefore, left them unsatisfied and seeking replacement) or the most expensive (which might have been overkill, again, pushing them to seek cheaper replacement). You do want to maintain as much of common core (code/features/etc) as possible so that your product lineup is cheap to maintain. Additionally, you want to make sure you can retain customers as their business grows, so you make your upgrade/downgrade path easy and simple.

To wrap up in a TL;DR:

product manager – CEO of the particular product. In the ideal world – person responsible for entire product life cycle, from idea to prototype to go-to-market.
planning product range – focus on fast go-to-market strategy, maintainability of the product and customer retention within your product line.