Categories
Product Management

Main Challenge As A Product Manager

Someone approached me on my LinkedIn and asked the following question: “What do you see the main challenge as a product manager and how do you advise me to overcome it?”

I gave the person a brief answer, but later on, I figured I should probably expand it. Here it goes.

There’s more than one challenge, but since not all challenges are created equal – let’s start in some sort of priority and let’s limit this list to three man challenges.

The first challenge for a product manager is their ability to listen and comprehend what their clients are saying. I’ve seen many PMs that “know better”. While they are still experts in the domain the failure to listen had resulted in failure to launch. Not because the product itself was bad – but because it became a solution looking for a problem instead of a solution for a known problem. Yet, they insisted – even after being presented with the hard evidence – that they know better.

The second challenge is to prioritize things. In many cases instead of prioritization based on customer’s pain points or specific goals the product manager prioritizes things that are dear to her (him) for whatever reason – because she was the one who proposed those features or she’s the biggest advocate of those features. It doesn’t result in major issues for the product, but could be fatal to relationships with customers. When customers see that no matter how many times they ask – they don’t get what they want, they will leave.

The third challenge is to be able to pivot or turn on a dime. Another way to express this is to “fail fast”. This topic alone has books written on it, yet people still manage to hold on to failing ideas because they’re so dear to them that they wouldn’t let go. The ability to fail fast: that is to try the idea and if it’s not working – dropping it and moving on – is still foreign to some people. Occasionally (but only occasionally) the problem stems from people being a “one-trick pony” and their concern (often justified) that they have nothing going for them if they’ve got nothing else. It is understandable but then these people aren’t in the right role for them. Product management is, probably, one of the very few creative roles within the classic enterprise organizations.
Alternatively, some product managers don’t fail fast enough because in their eyes the benefits outweigh the increasing spend (of all resources), when in fact it does not. Usually, this understanding comes with experience, but in a lot of cases, it is not hard to spot.

Ultimately, the three challenges: listening, prioritizing and pivoting fast are not unique to product managers alone – they are common for organizations as well. There’s a notion to call a product manager “a CEO of a product”, so in this case it is actually true – and the product manager is expected to be as wise as a CEO.

Categories
blog Product Management

Starting Up In Product Management While Eyeing Own Startup

Question: “Is it better to start off as a software engineer or as a product manager if you want to pursue your own startup in the future?”

You won’t be able to start off as a product manager (in a true sense of PdM responsibilities and experience, not in a title) since this role requires having a lot of experience from various disciplines. Product management (again, true responsibilities, not a title) is a multi-disciplinary field that requires a healthy mix of product building experience, technical knowledge, user experience understanding, design knowledge, and marketing expertise. These are not the things that people come to the table with right out of college or grad school – in fact, not many get to build these over time. In fact, I worked with many “product managers” who were stuck in one of the areas they felt comfortable with and not dared to venture into others. This would almost always make them very good in that particular area (say – technology), but rarely makes them good product managers.

With that said, if you are targeting your own startup in the future I think you better off coming from a different angle. Start off as a sales engineer or sales rep.

Why?

Because ultimately, no matter what you do in your startup, the only real metric of your success would be the sales figures. Even if the only thing you would have sold is your startup to another company – sales is probably the most important part of product life cycle.

As a sales rep/engineer you get an unfettered access to clients, their pains, wants and needs. You get first-hand accounts of pains and issues your clients want to solve using your product. This way you can be sure your product isn’t a “solution looking for a problem to solve”, but a true pain relief.

It’s very easy to justify NOT talking to your clients as a product manager because you’re too busy or whatnot. I’ve heard this pretty much from every single product owner and product manager (and I am myself was briefly guilty of this) – “I am too important and too busy to talk to customers”. Everyone has to grow up and out of this mindset. If you come to your startup already out of this mindset – you will have a greater chance of success. As a sales engineer or sales rep you don’t have a way to get out of talking to your customers – it’s your job.

As an insight – almost everyone with responsibilities of Director or VP of Product has sales metrics as part of their core KPIs. As a startup founder (or one of them) and a person who envisions and creates the product (assuming you’re eyeing a product startup) you would be responsible for product’s success. Unless you’re giving it away (and even in that case) – your main measure of success would be the number of customers. Being able to sell your product is a huge part of Product Manager (and above) responsibilities. If you are planning to start up your own venture, the ability to sell is probably just as essential as the ability to read, write and create PowerPoint slides.

TL;DR: start as a sales engineer.

Categories
blog Product Management

Product Development Process (from Quora question)

Question:
I’m often contacted to detail our product development process with other departments in my company. I am the CTO and the only developer within my company. I understand oversight, however, I believe there is a better way to go about this. What do I do?

Answer:
A few things strike me as odd.

  • You are the CTO. Which means you are responsible for strategy and the highest level of technology planning and execution across the whole company.
  • You are the only developer. Which means you are tasked with tactical day-to-day execution of someone else’s orders/asks/instructions based on someone else (again) collecting and prioritizing requirements from different departments.
  • Your company has other departments – this assumes you are not a one-man-show and at least have other people working towards company’s objectives.
  • Your communication with other departments is not transparent enough, so they end up asking about processes.
  • It is not clear if any processes exist
  • It is not clear if there are any other developers involved as consultants, freelancers or as an external vendor organization.
  • It is not clear what these departments are, but based on my previous experience I am going to assume that Sales and Marketing are among them.

Assuming you actually have those processes and is able to talk about them.

First and foremost – why is it important to be transparent about the processes of product development. Regardless of software developers, who may prefer to live in an agile world, most other organizations live in a waterfall. They often have to wait for a certain phase in product development to begin working on collateral, prepare PR statements, announcements, ads, one-pagers and whatever else helps to promote and advertise the product (even if it’s internal). You can’t just throw product at them and say “here, go sell it”. Additionally, early stage feedback (usually collected by Sales and Marketing orgs) is crucial to the product’s success.

Communicating “where we’re at” and “next steps” and “it will be ready by XX date” is paramount to the success of the product, not just individual departments.

Second – “Next Steps”. Marketing, Sales, and Support (at least these three) must know and plan ahead for the product launch as well as any upcoming releases. Marketing needs to be able to create materials promoting and educating customers on your product and changes to it. Sales must be able to talk coherently about benefits, new features and, in some cases, be able to say something like “this feature is on our product roadmap, it’s scheduled to be released in Q4 of 2018”. This alone may be a difference between securing a customer or losing it to competition. Sometimes customers may be tempted to convert to competition, announcing your plans may actually provide them with internal reasoning to stay with your company.

As you can see, at this point there are much larger reasons to be transparent about development processes than oversight. Other departments, most likely, want to look into your processes because it helps them do their job, not because they feel like they need to tell you how to do yours.

Now, being a CTO and the only developer can mean one of two things:

your company is very small – early stage startup small. This usually means that you really don’t have departments yet – you have Jake who does marketing, web design and creative copywriting and Jill who handles all sales calls, follow-ups, arrange your CEO’s calendar and probably does some accounting too. In this case – just go over to them and talk.
your company is not very small and you outsource most of your development, making you the only developer within the company’s ranks, but not the only developer for the product/company. In this case, I may suggest looking at your priorities – do you want to write code or do you want to strategically manage technology for your company or product. If you want to write code – drop the title, focus on engineering aspects and let someone else lead. If you want to be the CTO – stop focusing on a tactical day to day tasks and focus on a big picture. I am not saying you can’t do both. I am saying if you continue doing both you will not be effective. It’s not just my opinion – check, if you will, Peter Drucker’s “The Effective Executive”. By doing both you’re diluting your time that should be spent somewhere else. Time management is one of the most important aspects of being an effective software engineer, but it’s absolutely positively the most valuable asset of an executive.

Bottom line – the ask for more transparency comes from other people who rely on you to deliver things, but that can never be sure what is being delivered, when and how. Oversight is the last reason on that list.