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.

The post Main Challenge As A Product Manager first appeared on Blog about business and product management.

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.

The post Starting Up In Product Management While Eyeing Own Startup first appeared on Blog about business and product management.

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.

The post Product Development Process (from Quora question) first appeared on Blog about business and product management.

Another good skill to have is what recruiters like to call “business acumen”. Not sure if they know what it means, but in the classic sense – as in “keenness and quickness in understanding and dealing with a business situation” (source: Wikipedia – Business Acumen) it’s an amazing skill to have. Among other things it allows you to quickly evaluate your own product from a market’s perception and understand if you have a “solution for a problem” or a “solution looking for a problem”. You want to have the former and avoid the latter.

Being able to question everything. Especially – do question the set ways to do things – this is mostly where most of the problems are. Failure is a journey too. If a “user” experiences a certain “pain” – he/she will definitely try and resolve it. When they fail – at least a couple of times – they will hire someone passive enough to “do as they told” and “be quiet” and “not to argue with the boss”. That’s how “ways to do things” are set. That’s how you get people running hundred rep call center from a spreadsheet. That’s how you get people to stop question their commission payments because “no one can analyze hundreds of thousands of rows each month in a single Excel spreadsheet”.

Because “reasons”.

Knowing your technology, what is possible or not possible, or having subject matter experts available. I had a lot of experience developing regular software so I could easily anticipate what can be done and what cannot. When paired with the questioning of the “ways to do things” – it may seem like magic to your customers. A real-life anecdote: “No one was ever able to reconcile these commissions automatically and we can’t do it manually either – these Excel files are huge and have to be downloaded monthly by hand from a password protected portal”. – “What if I can automate the download and import the data into a database. Can I match this against that automatically?” – “I don’t see why not” – “Then we can 100% automate your reconciliation”. – “Wait, what?”

Learning skill. This is probably the most important. In your journey as a product manager, you inevitably will end up with a problem which will not be solved using your existing skill set. You will need to learn something new. This will happen constantly, the more areas of your customers’ lives you will touch. Within 2 years of my previous job, I’ve learned a ton of new stuff. How informal negotiations work. How salespeople talk to customers behind closed doors. What do CEOs talk to each other about and how when they’re partying. How partners in a business fight and how they find ways to resolve their conflicts with minimal impact to the business – and how they fail to maintain the resolution. And, ultimately, how each of these factors affected my own product and its journey.

All others are important too – a product manager is a CEO without a company, so in almost all cases you can’t just delegate the task to someone else. Especially in early stages of building the product you get to do EVERYTHING yourself. Marketing collateral, managing developers, juggling projects, negotiating resources and timelines, hell – sometimes you end up building your product website in a spare time because no one else can build a website for something that doesn’t exist.

Last, but not least that I wanted to mention is the ability to go on. “It’s the courage to continue that counts” and in the world of product management it is the only way to build useful and successful products. Within one year I have tried to create at least a dozen products that solve one problem or another. Nine of them failed completely. One produced a freebie that was great for retention but didn’t make any money for the company directly. One failed, but from the salvaged parts the company was able to build a completely new line of business that became pretty successful. Another one (potentially – as I am not with the said company anymore) is another new successful line of business. What if I had stopped after the first three failures? What about six? If you think you need to draw the line – you don’t. You just keep going.

The post What types of skills are needed to become a Product Manager? first appeared on Blog about business and product management.

This one is easy – you do the same thing you would have done after University – only without it. Let me elaborate. One thing I have learned through my 25+ years of different careers in IT and around is that university degree, diplomas, and certifications have very little – if anything – to do with actual performance on a job. At least once in my past 10 years, I was hired against the rule of “everyone should have at least a Bachelor degree in this company”. I also was officially denied a consideration for employment at another company once because of lack of Bachelors degree. That was after I’ve got a solid 10 years of experience in the industry. I guess those two cases cancel each other out.

What defines me as a “knowledge worker” is not a degree or a certificate. It’s the actual knowledge. Granted – given a good education (and by “good” I mean – as close to a real deal as possible, not just expensive one) a lot of things get easier or more transparent. A lot of other things, however, become invisible. You need a special knack to “uncover” things, persistence to do this all the time and actual intelligence to recognize the “AHA!” moment to be able to succeed.

A degree may (or, rather, should) supply you with a set of tools – the quality of them would vary based on your teachers and their methods, but at least you’ll get the basics. Without a degree, you’ll end up developing your own set of tools that may or may not be better than those imposed by education. The upside is that they will be yours, so – ultimately much more convenient to use more often.

The way I have become a Product Manager was through working in various roles in IT – tech support, software engineering, technical leadership, project management. At each stage, you can see various pieces of the puzzle, but usually until the level of manager of “development” or project manager the whole picture will be obscured. This, however, allowed me to build my own set of tools to determine and paint that big picture without having direct access to assets (people or systems) that can define it for me.

Once I was able to get to the big picture for existing systems – it became a lot easier to create my own big picture where there was none before. Because a product isn’t just a piece of software that does A, B and X. A true product is a solution to someone else’s problem. I’ve used this line in one of my other Quora answers, but I’ll repeat it again: “Don’t think about how to make your product better. Think about how you can make a life of your customer easier”. Any successful product would be one that resolves a customer issue or takes away or eases the pain.

Ultimately, to become a Product Manager to start thinking about yourself as a product. What kind of problems will you be able to solve? How do you go to the market? Where is your audience? What are the definitions of your own success?

Well, the last one is easy – once you have solved a couple of real-world problems with a product of your own – you can start thinking that one day you will be a successful Product Manager. I certainly think I will.

The post How could I become a Tech Product Manager without University? first appeared on Blog about business and product management.

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.

The post As a product manager, what are some anecdotes you find yourself using often? first appeared on Blog about business and product management.

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.

The post What are the pros/cons of having a product owner? first appeared on Blog about business and product management.

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.

The post What does a product manager do? first appeared on Blog about business and product management.

With this said – keep reading, subscribe, etc.

The post The Pivot Point first appeared on Blog about business and product management.

So why, even considering all the points from previous post, it may still make sense to have your web site on someone else’s ground?

1. A Large Community. If your product is, ultimately, a text (reviews, blog posts, rants, whatever) – you are writing for other people to read and respond. Having a community around helps a great deal – people are more likely to respond when they are a part of the same network. That’s how Tumblr, Medium operate and that’s why Livejournal is still twitching although it should have died painful and miserable death years before MySpace. Having a community is probably the heaviest argument towards having your blog on a network vs. hosting on your own. You can (and probably should) crosspost back to your own blog for the reasons stated in previous post (network may shut down or make your posts invisible), but ultimately the easier people can interact with you and your blog the better. Same can be said about the likes of Etsy or eBay – it’s a marketplace where people come to buy things, so you may just as well participate. The more channels you sell through the better.



2. Performance Considerations. If you are on your own and haven’t made it big time yet – chances are your site hosting resources aren’t anywhere near the capacities of big players. Sudden spike in visits or (let’s think positive) a steady surge may send your web site into a crawl or make it unavailable. Big networks almost always can handle high loads better. Additionally, there are services that are tailored for supporting specific platforms (like WP-Engine for WordPress blogs). Their costs are usually slightly higher than ordinary hosting’s but they will take care of the shining the bells and cleaning the whistles of your platform.

3. A Piece Of Mind. Knowing that a dedicated team of developers whose (hopefully) full time jobs are keeping your site up and running makes it easier to concentrate on other matters of your business. Of course, you can always get a case of LiveJournal, that has been steadily progressing from bad to worse to completely unreliable, but it’s rather an exception. Picking a right resource may just be good enough to do the job you want it to do. Compared to finding a developer or a team that is capable of steady performance given the intermittent task structure you inevitably will have is a deed of it’s own.

4. Price Considerations. If the hardest technical challenge you ever overcame was changing background on your iPhone to your selfie, taking care of technical matters may end up being too costly – with finding and paying the right person to support your site and all. Paying for service that does just the right amount of work for you may turn out to be less expensive while providing enough features for your needs. On top of that hosting and maintenance of well known popular platforms is almost a commodity now, so large companies can give a better price compared to small time shops.

5. Features That Otherwise Would Be Hard To Get. If you don’t know what “PCI compliance” really is – you have never really done e-commerce. Additionally, certain providers may allow you to accept payments in different currencies, add marketing features or sell goods that otherwise would be impossible or too complicated to set up on your own. Some (like Amazon) will even warehouse your inventory to shorten the trip to the consumer. Such features are hard to beat especially when they come as a part of a package.

6. Security Considerations. In these days where even big names like Target and Home Depot become victims of hacker attacks it’s easy to imagine that breaking into a small time shop on a small time server wouldn’t be a big deal for a determined hacker. By sticking with a larger provider you reducing the risk of being brought offline and in case it happens – reducing the downtime itself. Large companies have the capacity, knowledge and resources to employ security solutions that are way over the head any small or medium businesses. There is, of course, no silver bullet, but decreasing chances of downtime is worth paying extra if it comes to that.

7. Scalability. You are building your business to grow. So what if your site starts getting ten times more visitors, or even hundred times more. The platform you used before may not be enough – either your server is too weak or the platform you chose isn’t optimized. This could be a pretty scary race against time when you scramble to find people and make decisions on how to upgrade or where to move without full understanding of what you really need. Having a (supposedly) highly qualified team that could answer these questions in an instant – just because they’ve been down that road before multiple times – is invaluable, especially when your web site is crawling under heavy load of new clients.

It’s rather obvious that no single tool is good for all jobs. Picking whether to get your own piece of internet real estate or get into a community with shared parking lot and garbage collection is an important decision that directly affects the future of the business.

The post Own vs Rent: Why Hosting Your Web Site On Someone Else’s Platform Is A Great Idea first appeared on Blog about business and product management.