Showstopper, is this a show?

So you have a showstopper. First is it even the right word. If you take one step back and look at the situation and all involved, its now the show begins.

Ok, late in the testing something is found. Your new version is not performing up to specs, you have something that is so big that you stand there with a showstopper, while the release date is getting near. The phones, emails and other communication devices are being heavily used as everyone tries to understand what it is, what went wrong, and how to avoid blame. There is the show, so it may be that a Show Stopper is a Show Starter.

It will however be much easier if you as a product manager take the lead and if you understand why the others behave as they do. Only then can you find the acceptable way forward and try to get the product out without the organization failing around you.

Project Management

Your project manager really wants to know what happened and what should be done different next time. Excellent questions, but try to convince him/her that these questions can be dealt with when the Show Stopper is dealt with. How to learn from this is not the primary task right now, it is to fix the mess. Get the project manager to look forward and help you find creative solutions.

Release Management

Who committed the release date in the organization? Right release management, so who want to do anything to keep it? Right again. But a delay may not be that fatal. That you delay the release to make sure that the quality is good is something that could be positive. Convince your release manager that the quality is the foremost, not the date. Take help from marketing if needed. Do whatever it takes to bring your release manager on board in getting the product out to the customers as soon as possible, but not before its worth delivering it.

Quality Assurance

It may be that QA found the show stopper, or it may be that they missed it. Now they will do anything to do all testing all over again when the error is fixed. But is that necessary? Involve QA in identifying the error and also assess how the fix is applied. It may be that if they get sufficiently involved they may find a better way. It may be that the can accept to just retest relevant parts. Help them get to that conclusion, involve them in the process. See them as your ally (really they are that). They have the same goal as you have, get out a product with GOOD quality.

Development

And of course, someone produced the bug. But really, right now is NOT the time to assign blame. Identify who is the best to fix it, work in teams if needed. Make sure the fix is solid and well documented (you need that when dealing with QA). Then later on when the product is released (on time or later) its time to ask the question “what can we do different next time”

Sales and Delivery

When trying to get forward after an abrupt halt make sure that sales and delivery is not hurting to much. They have tight schedules, they are the ones getting the reactions from the customers, and they know if there are any contractual obligations or not. In short, they provide you with the information you need to have when deciding if work is around the clock or not. Just make sure you differentiate between MUST and NICE. If they say it MUST be released before weekend, ask WHY, ask about contractual obligations and project plans. Make sure they don’t pull the must card once to often.

Conclusion

Cooperation and a clear target are the two most important things. You as the product manager are in a unique situation to get everyone else to cooperate. Make sure you listen to them, factor in their input and then get everyone to strive for the same goal.

It does not matter how many cool features you have if you don’t have the basics in place. Think if a car manufacturer just forgot about door, but they had the best engine in town. Google did just that.

We were all envious of a certain product manager when she showed Google Wave for the first time, think about being part of something so cool and new and different. Not many of us are in that corner of the universe, mostly we just work hard with existing things to improve them. Then we got invites to this Wave and started using it. And some even got all their friends on the wave, like my friend Naive Project Manager. And then one of his project participants decided that the grass was greener elsewhere. So no problem, just hand in the security card, the computer and the google acccount.

Well, the google account is connected to the gmail account and that one is probably a personal account, not a company account. So the Naive Project Manager decided to remove her from all the waves, and met a greyed out button. So the functionality is not even there. It’s documented that it’s not there, the existence of the button show us all that it’s not something they just forgot to put in there.

It’s something that was thought of, a problem not solved, so they released it anyway. Yes it’s in Preview mode, but gmail was in beta for a long time, and so was other google products. The whole world has been used to use google products that are in beta. And this time it failed.

A fundamental feature like delete a particpant from a wave must be there. It’s just like thinking about putting doors to a car and then don’t, but put the handle in place.

Its a failure, and I hope Google is correcting it soon. There are a lot of naive users out there, they should maybe be more reluctant to use new things, but whenever has that argument worked?

How to free up time

So you have your new shiny version of your product out on the market and everything is fine, just leaning back and rest for a while. The customers will attend to themselves, right?

It would be great if it worked that way, but as soon as the first customer starts using your product it will need support. And the person doing the support will need knowledge about the product (more than the customer), and also have the means to look things up behind the product. So that person must be pretty good at both the product and at diagnosing errors (product or users). But who will that person be thought by, and who will that person go to when it does not work?

If you by now have a funny smile on your face you have guessed right. You as the product manager are supposed to be even more knowledgeable in the product and as you are the product manager you can answer all questions, search for any errors, get anything fixed and released yesterday. That is where you have to think long and hard about

1. What do you think is your task?
2. What is not your task?
3. How do you communicate the answers to the first 2 questions?

Your tasks

What is your tasks depends on what company you work for, but I will give one answer. The important thing is not the answer but how you define it and how you use it. When releasing a new product someone must educate support, sales and delivery in that new version. There is a couple of different persons that could do that as they have developed the new version, or tested it, or written the documentation. But who knows best the intention behind the new or changed features? That is you. And the best way of getting the right information out there is to be involved in delivering it. So first task is to spread the word and educate in your new version

So after that is done they should know everything and stop bugging you? It’s not that easy, I will now give some hints for how to handle different user groups in your own company

Support

When its out there and support starts getting in you will have to be available to answer the questions you failed to cover in your training or they failed to remember from the same training. But make sure you dont have to answer them again and again and again. Put it in a wiki, faq or on the intranet.

Make sure support looks there before they go to you, if the answer is posted don’t just sigh and give it again, point them to the answer, otherwise they will continue using you as their personal assistant.

Sales support

As we all know without sales we are out of our jobs. So we should support them, but that does not mean that we have to do their job. See to it that they have all the information they need to fill in thoserfp :s themselves, and when they dont have it, make sure that you update the Wiki/Faq/whatever that was lacking the needed information. It works more or less as with the ordinary support. Just dont do their job, help them do it.

Operations

If you are a product manager in the software industry you are likely to have some sort of hosting within the company. They certainly are gods at all their servers, protocols and firewalls. But they are also very likely not being sogod like when it comes to the application. When it’s an “application error” they just turn to you and wait for you to fix it. Your task is very likely to be to assess the errors and rather prove to them that it’s not the application that is at fault when everything is slow. Make sure that the burden of proof is with them instead. They should search for the reason of any error and provide you (and developers) with all relevant information BEFORE they just say “not our faults”. If you let them behave like that its very hard to correct it later. So make operations responsible for all operations not just their beloved fire walls.

Bugs vs New Features

All of the above mentioned populations will every now and then find an error in your product and they all want it fixed NOW. or they just want to change a little tiny thing and surely you can do that NOW. If you start doing that you have lost the battle and in the future that is all you are going to do. Even though you sometimes tries to sneak some new features into the products against all common processes on how it should be done, don’t let others tell you when to do it. You have the strategic view of the product, support just have ONE customers view (its uncommon that they have more than one customers view at the same time but it can happen). And bugs are bugs and they are not new features, they are not part of the roadmap, and yes they should be fixed, but not by you. Make sure there is a bug fixing process that can handle itself without your constant involvement. BUT, make also sure you can reprioritize in it. Some bugs just may be so important that you need them fixed first. Yes that’s your task as the strategic thinking product manager to identify the bugs and errors that may harm you in the market.

But the customers?

Yes the customer, the most important person in your company its said. But are they your responsibility? If you provide support and delivery with all info they ask for, and more, you should be able to also make all customer handling their responsibility. Certainly you should meet them, but a meeting with the product manager should never be first action when a customercomplain , it should be used with care. See to it that everyone have the info they need, and make sure they use it. Your time should be spent on productive customer visits, not only to try to impress them “see we take yourcomplain seriously, we even bring our product manager”. Make your time a valuable asset, not something to use instead of solving the problems by support and delivery.

To sum it up

As the strategic thinking and planning product manager you are you must make sure that everyone else have the right information and that they know where to find it. That’s the only way to make the time you need available to being strategic. Putting some effort into the documentation and training issues for other internal groups is well spent time, as long as it frees up your agenda for other tasks.

Not so brutal today, still honest

Had a great day at work today, and a few break throughs in topics we’d been chewing on for a while. A long while. Like, chewing on them for so long that our teeth had been down to the gum.

Anyway, re-read Saeed’s post about the Variety in PM Blogs and learned that this thing here is an <adjective> blog. Honestly, after only a handful (OK, really honestly, not even a handful) of posts, not the worst mention possible.

Then realized that while Cranky PM definitely was inspiring, I’d like to make it crystal clear that brutally honest does not equal cranky, etc. Honest can go any way, positive or negative.

Therefore, I’ll be brutally honest about the following today:

Why I love my job.*

Call me a sentimental fool, I can live with it.

Here goes:

• The mix. The crazy, wonderful, terrible, overwhelming, challenging mix. Go from the detail level to the strategic level in a second, and back. Think software, business management, leadership, performance improvement, external communication, internal communication, sales, de-escalation, design, and so much more. All in a day. Sometimes an hour. When lucky, or especially inspired, all at the same time. Love it.

BHPM advice: If this sounds terrible to you — do not consider a PM job.

• The team. The annoyingly clever people around me. Those developers who are always right and ahead of the curve. The designers who surprise you. Every day. The devotion. Love it.

BHPM advice: Hate people? Don’t even think about being a PM.

• The leadership and evolvement. Seeing people get better in what they do. Love it.

BHPM advice: See above, plus: Let people evolve, let them do their own mistakes. While you are busy doings yours.

• Ideas becoming reality. There are times when I stare at my requirements and user stories and think, how is this ever going to happen. And then it happens (with a lot of hard work from everyone involved). And that’s just wonderful. And then someone objective tells you it is the best they have ever seen (OK, not always, but it happened at least once). Love it.

BHPM advice: Enjoy those rare moments. Most of the time, people will only mention the gaps and failures of your software when speaking to you. You get lists with reasons why deals did not happen. You never get a list from sales stating why deals do happen thanks to the hard product work.

• The money. Let’s face it, we like getting a salary, and those bonuses. Business is about money, and therefore the business you work for expresses your value in – money. Love it, too.

BHPM advice: Negotiate your compensation package hard, and wisely. Prepare. Have your arguments together. Get benchmark numbers and use your network before negotiation.

—

* Not always. But when I do, one of the reasons listed is likely to be involved.

Lets take a look at the stake holders

BHPM just got mentioned on a post by On Product Management and was urged to post more, so here comes another post.

So everyone in the company is telling you what to do? Release Management says you are late with requirements for the release. The Developers are waiting for you to tell them what to do and documentation team thinks you have to provide them with input on messages in the system. And that’s just a start, virtually everyone is a stake holder and not only are they all waiting for you to do something, they all think that they have to tell you what to do and when to do it.

BHPM have news for you. You are the Product Manager and you tell them what to do and when to do it. In this post we will deal only with the feature sorting, release forming aspect of Product Management. There are other aspects of the role but one post is to small to deal with them all.

Requirements

Let’s start with Requirements. There are a number of different ways to collect requirements from the market, customers and sales and everyone else. BHPM won’t cover them here as they are covered elsewhere. But when the requirements are collected it is the Product Manager who sorts them, prioritizes them and puts them into a release. Not sales, they are our resources to help us collect the requirements, and when we deliver the product they are the resources to get it to new customers. But they are NOT dictating the contents or time lines of the releases. So please try to avoid being hostage of sales, they have a tendency to sell what they want and then you just have to deliver it. Make sure you have the backing from Management to don’t do that.

Release Management

The Release Management is truly important as they hold the release together, watch over the Project Management and sees to it that what Product Management put into the release gets delivered. But they are not the ones forming the release content, that’s a Product Management task. They are also not the ones setting release dates. That Product Management does together with Company leadership. Release Managements primary task is to take the requirements and get them delivered to the market. They are the ones that see to it that Designers do their job. Product Management is the ones signing off on the actual work that Designers/Developers does.

QC

QC is truly important, without them the product is probably not worth releasing to the market. But they are not the ones dictating what to release. Their job is to make sure the Quality is good, nothing else. They are valuable sources of information, but what to do with that information and how to use it is up to the Product Manager. Listen to them as they often have valuable insights but don’t let them dictate. If you postpone something that’s your decision. (and its a 100% sure thing that you will have to answer for it later, so why dont also make the decision?)

Documentation

Documentation team is responsible for putting the documentation together. In some cases that could also be an online help system and error messages. But don’t let them tell you that you have to form the documentation content, that’s their job. They are to form the content of the docs and organize it, Product Management is to require it, revise it and approve it.

Developers

And lastly the developers, great people doing their work. But they are developers, should work after the specs and not after what they think. Sometimes they have valid questions or suggestions, but if you say NO that’s the final word. They are to deliver what’s in the specification, nothing more nothing less. If they have a suggestion that you think is good and you can do it within the time frame, remember to update the spec (and you are not the one doing that work remember).

So conclusion

Everyone in the company loves to tell you what to do and when to do it. Truth is that you are the CEO of your product. You listen, take advice but at the end of the day you make the decisions, and have to defend them. If you don’t make the decisions how are you to defend them later?

This cloud computing thingie

Hi there, we kick this off with a topic that has come my way lately a number of times. It usually goes like this.

Customer: Hi does your software do cloud computing?

BHPM: What do you mean by that, what do you want it for?

Customer: I don’t know

 

So the customer (usually a 50 year old man) asks something he has no idea what it is and why he wants it. But Hey, it’s a cool new concept so its must be something we need, right? WRONG! (or #fail as its called on twitter)

 

What is cloud computing?

It’s not an easy question it seems, even the article on Wikipedia is marked “needs reorganization to meet Wikipedia’s quality standards.” 

But BHPM will try to make it really simple. Although BHPM will not try to give you a full explanation and overview of cloud computing. If you take your average application, stop hosting it in your old data center from 1970 and start hosting it in a data center on the Internet where a number of other are hosting a lot of different applications (multi tenancy), and that data center can provide you with computing power to cover your spikes, and bills you what you consume. Then you are doing cloud computing. It can also be storage capacity or maybe band with.

Look at it like your electricity bill. You pay for the electricity you use (and maybe some flat rate for using the cables), and during winter you can use more of it as it is cold outside without having to bother about investing money to get more electricity. Cloud computing is just like that.

 

Requirements for doing cloud computing

Of course it’s not exactly that simple, but let’s say you have an application that is web enabled then go ahead and stuff it in a cloud. If you have a 40 year old COBOL application it will be a little more work, but there are solutions out there for you (have a look at Micro Focus) . But when it comes down to it. Cloud computing is nothing special (and some old main frame buffs would say it’s not even new).

So when you get the question if your software does cloud computing the answer might well be ”yes if you want it to” . But please remember if you are offering the customer a hosted environment (Could be as Software as a Service, SaaS) its not cloud computing (unless you host your entire SaaS offering in the cloud) but it might well be cheaper for the customer as you probably have built a data center with expertise around your specific software.

 

So what is it not?

And here we come to one of the biggest misunderstandings. Just because your software is hosted in the cloud, and you have several systems hosted in that cloud does not mean they automatically start talking to each other. To get them talking you still need to do data mapping and all other tedious integration work. It’s just not happening by magic.

Even if you have a bunch of systems littered with SOAP interfaces and Web Services they don’t by magic start talking to each other. They never have and never will regardless of what all the sales reps in the world are saying. And it’s just like that in the cloud, you still must make them talk to each other. Yes, it might be easier once you have it all there, but you still have to do it. 

 

Conclusion

Next time that ignorant 50 year old man comes to you and asks about cloud computing, either you just sigh and say “yes of course” or try to engage in a conversation of what he really is after. It may be that its SaaS he wants, and have it all confused. It may also be that he want to integrate your software with some other, and if thats what he wants and you say “yes of course” it could lead to a lot of misunderstandings.

So BHPM:s  advice

Ask him what he wants, try to probe the matter so that you both agree on what the goal is. Only when you have done that you can start devising a good answer and maybe an action plan.

Let’s be brutally honest about Product Management!

Is it a good idea to start a blog after a few cocktails? Well, the motto is to be brutally honest here, about Product Management and everything else. So we will just give it a try, all right?

 

See what this is all about.