Software Product Manager by Gopal Shenoy

From time to time, when I talk to other software product managers about their biggest challenge, they often say that managing internal stakeholder expectations is their biggest challenge. Yes, of course. After all, product management is like herding cats. Sales goes and makes promises to customers without asking the product group, marketing wants their projects done first, your development team has their own pet projects, customer support wants customer’s burning issues fixed first, professional services want projects that will make them do implementations faster. And all of this needs to be done in a short time with limited engineering resources.

So is there a way to manage these expectations and make sure there is a clear product direction? I have been using Product Council meetings to successfully do this. Product council is a concept I picked up from Marty Cagan’s Inspired: How To Create Products Customers Love book. I strongly recommend this book to all product managers.

So what exactly is a product council meeting and how do you run it?

Product council is a meeting with the executive management (including the CEO) once a month to review the product strategy and the product roadmap and resolve any conflicting product priorities that are currently in play. You as the product manager or head of product management should run this. This way, everything is presented in an impartial way and the whole group is presented with the projects that the product and engineering team is currently working on and need to work on in the future. If there are conflicting priorities, you present the pros and cons of the priorities and ask for a resolution from the product council. Make sure that the stakeholders whose priorities are creating the conflict are in the meeting. Be clear that you want a resolution at the end of the meeting (not afterwards) because the product team needs to start working on the right project(s) based on the decision. Force a decision by the end of the meeting.

I often hold these meetings once a month for an hour. It is a standing meeting that is on every stakeholder’s calendar. The agenda is typically the following:

1. Review the product strategy
2. Update since the last product council (what have we done since then)
3. What are we currently working on?
4. What is ahead of us?
5. Review product roadmap
6. Presentation of any conflicting priorities
7. Final decision on prioritization

It is important that you as the product manager or as head of product management help the executive management see the conflicts and lead them through a prioritization exercise. Once a decision is reached, there should be consensus from all stakeholders because it is an educated decision made based on review of pros and cons of each priority and more importantly facts (instead of someone’s opinion or support for pet projects).

So are you done after product council? No. You have to make sure that you keep the product council abreast of progress being made on the new priorities. If the project hits a bottleneck because of some unforeseen technical or business related reason, you need to immediately raise it to the product council rather than waiting till the next meeting. Communication is key to managing stakeholder expectations. If you do this well, you should be able to effectively reduce your stress level as a product manager.

Thoughts? How are you as a software product manager managing stakeholder expectations?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.

A company has success with its enterprise product. But the company wants to accelerate sales and increase the number of customers.

Someone says – how about small businesses? Of course, that is a large market. Why did we not think of them? We already have the enterprise product in the market – so building the small business version should be easy.

The CEO says “Get rolling, I want to ship a small business version next month.”

Everything is fast tracked – product management starts with the enterprise product, cherry picks features to turn off and voila, small business product definition is done. That was too easy. What about pricing? Hummm, let us see, how about 60% of the enterprise product? Done. Product ships, everyone is excited on launch. There is a party, the CEO is thrilled – the team delivered.

Roll forward 30 days – the small business product is not getting traction. Sales comes back to product management with requests for one-offs – “hey, I was talking to this company – they love the small business version, except they want this one more thing that is in enterprise version – do you think we can turn it on? After all it is there, should’nt it be just easy to turn that switch back on.” Sales applies pressure because they have to meet their numbers for the quarter and it is so enticing to do this because no new feature has to be developed – it is already in the product!.

Unfortunately, this is a common story and I have personally lived through months of the above. Welcome to the world of customization hell. It is worse than the enterprise product because what the company has essentially done is allowed customers to demand the enterprise product functionality at steep discounts, now that you have two products – the enterprise version and the small business versions. This is not limited just to small businesses. Enterprise customers get wind of the small business product and want the small business version but with feature X, Y and Z and at the small business price.

When building products for new market segments such as small businesses, companies often make the mistake of creating a product by turning off a bunch of features from their enterprise version and slapping “for small business” on this watered down product.

This fails for one of two reasons:

1. The product even with some features turned off is still considered too complex by the small business users because the needs are different and also the persona of the target user in small business are different.
2. Small businesses have the same needs as larger businesses and hence they find that the watered down product does not satisfy their needs.

Let us examine these two issues in more detail by considering two examples.

1) IT network monitoring product: Large businesses tend to have an IT staff in hand to set up their networks. These highly qualified staff typically are geeks and take pride in the fact that they have to use DOS prompts and unix like interfaces to get their job done. Now consider a small business which has to set up a similar network. Very often, in a small business, it is probably the owner that may be setting up the network – he is not an expert at networking, wants to quickly set up his network and get back to business and has no time or expertise to deal with DOS prompts and Unix like interfaces or to understand networking terminology to set up his network. He wants a very simplified interface that hides a lot of complexity, wants to select a few options and have the network up and running as quickly as possible.

Now let us take another example -

2) Performance review management software: Companies do performance reviews either on an annual basis (everyone gets their reviews done at the same time) or at the time of employee’s hiring anniversary date. The software vendor decides to offer these two options only in the enterprise version and turn off the capability to performance reviews at the employee’s hire date in the small business version. This does not work out because even small businesses have the need to do performance reviews based on the employee’s hiring anniversary date.

How to do this right?
So how do you avoid these two traps. Here are some ways to do this right -

1. Clearly understand the needs of the small business user. It takes the same amount of time and deep understanding as the enterprise product to get it right.
2. Clearly understand the persona of the user who will potentially use the product before you decide what the product needs to be. More often than not, you will find that usability tolerance to be vastly different between small businesses and large enterprises – not that large enterprises don’t like user friendly products, but they are a little more tolerant because of the resources they have to handle implementation and ongoing maintenance.
3. Make your product offerings by balancing the needs of the users and your business goals. If the functionality needs are the same, make the product offerings different on other variables. For example, you can impose limits on the number of users who can use the product or by by pricing your product as per user. This way small businesses can get all the functionality they need, but pay less fees depending on the number of users they have. Or limit the amount of data they can store – for example, the enterprise version of a CRM product could allow saving unlimited number of contacts, but the small business version may allow only upto 1000 contacts. If it is a survey software, you could segment based on the number of surveys someone can run per month or by putting a limit on the number of responses you can get per survey.

In essence, simply watering down products is not the right answer.

Thoughts? Do you agree?

If you enjoyed this post, please spread the word about this blog, consider leaving a comment or subscribe to the feed to receive future articles delivered to your feed reader or via email using the text box in the column on the right.

Events force actions – this has been such a guiding principle for me that it has allowed me to get clarity when there is none, has kept me focused when I have been distracted by too many things to do, has helped me achieve something because the deadline is looming. For example, I am about to leave on vacation and the last two days have kept me laser focused on getting things done.

I have blogged in the past that everything needs a head and a date, otherwise it will never get done. So everytime, you think you or your team is not making progress towards your goals, create an event and drive an action towards it. The event is essentially a milestone such as an alpha launch date, beta launch date, a demo or presentation to the executive team or usability testing with customers. Once you have got others to commit time to an event, you or your team has to react and get moving. You will be surprised how such a simple action on your part can energize the whole team and get things moving.

Thoughts? Are there any additional ways you have energized you or your team to get moving?

Product Camp Boston is this Saturday – May 22 at Microsoft New England Research and Development Center. If you are a product manager in the greater Boston area, have you registered yet? If not, what are you waiting for?

If I get selected by attendees,  I intend to run a session called Managing your product management career. If you attending and are interested in knowing how to build your personal brand so that you stand out as a product manager, how to market the only product you are fully in charge of – “YOU” and also get some practical job hunting tips, please vote for my session.

Growth in business puts scalability and performance demands on the software product that the company provides. These demands could take the form of site accessibility (number of concurrent users) and also number of exceptions that need to be handled by the system. Issues caused by increase in the load experienced by the product is well known (solved by load balancing, more servers, well written web pages such that it can load faster etc.). I want to touch upon an equally important scalability issue which is related to the number of exceptions and their frequency.

So what do I mean by an exception? I am not talking about exceptions from a software programming sense where the concept of try-throw-catch statements to handle anomalous situations in the code is used. Instead, I am talking about anomalous situations that can happen from a user or a business process perspective. Let me clarify more with a simple example.

Assume that our product does one thing – takes a full name, typed in by the user and splits it into first and last name before storing it into the database. Sounds very simple. If the user types in “John Smith”, first name = “John” and last name = “Smith”. Everything goes well but over time, until the system starts encountering names it had never seen before. Names such as:

1. John Doe Jr.
2. Safraq Ahmed Naveed
3. B. Sunil
4. Rajeev Kumar P.C.
5. DÖRTHE Austerlitz
6. Timo Gärtner

Let us take the second and third names in the above list. In the case of John Doe Jr., you don’t want the system to store the last name as Jr. and refer the customer as Mr. Jr. in the emails it sends him. In the case of “Safraq Ahmed Naveed”, what do you do with the name “Ahmed” – is it part of the first name or last name? Can your product handle special characters such as “.”, “Ö” or “ä” in the names?

Such problems should also be considered scalability problems. It may not cause site performance issues, but it could prevent users from using your product. I have used a very simple example to illustrate the issue. But in the real world, when such exceptions are encountered in the core business process, things can take an ugly turn not only because of the number of the types of exceptions, but more because of the frequency at which each of this happen. What used to be considered an edge case when you had 100 users could quickly turn into a mainstream use case when you have a 1000 users. In my career, I have experienced numerous such issues – all of them sound trivial – but that could have caused major impact on product usage. If you are running a consumer facing website, you may not even know about these use cases that are affecting your business because customers turn away when they find that the website cannot even handle what they consider a simple use case (one that applies to them, but which in your books is an edge case).

As software product managers, we need to be aware of these exceptions that may be raised because of expansion into a new international market, a new vertical etc.

Thoughts?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.

In my software product management career, I have worked with remote software development teams in India, China, Australia, Ukraine and the UK. In many of these cases, we were working with outsourcing partners. I have been wanting to write a post reflecting on what actions ensured success and what resulted in failures. It has been on my to do list for a while – like a year.

Software outsourcing is always pitched as easy to do. Common benefits that are advertised include 24-hour development day (they are coding while you are sleeping!) and the large cost benefits through hiring cheap but good talent off-shore. While there is an element of truth in this, it is also a double edged sword. The 24-hour development day can be advantageous or disastrous because a lot of bad decisions can be made by your partner team while you are sleeping. The time it takes to discover these and then rectify them is at least 48 hours. Developers overseas are also typically cheap to hire because of the favorable currency exchange rates, but if you don’t set up the right infrastructure, you could lose precious time and money because of bad architectural decisions, poor code quality, major integration issues etc.

Last week, I was forwarded a slide deck on outsourcing and its common pitfalls. This deck captures the valuable lessons I have learnt over the years working with software outsourcing partners. It in fact captures it better than I could possibly have.

This is a must read for anyone who is doing outsourcing, who has been burnt by it or who is looking to explore an outsourcing model for software development. Consider this a good 5-10 minute primer.

As full disclosure, Sitrus who has put this presentation together is the outsourcing partner in Ukraine that I had worked with and are one of the better ones I have worked with. I am not paid anything to pitch their name or to do this blog post.

Thoughts?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.

It is our job as product managers to find out why our customers “buy”. Buying is a very emotional behavior especially when it comes to consumers. When selling B2B products, the purchase cycle typically follows a chain of events – RFP to demos to pilots to implementation to release to production. But what about consumers? How do they make buying decisions?

It is very important that you delve deeper into the customer’s lives to see what influences them. For example, on eCommerce websites, shopping cart or checkout abandonment is quite common. This is one of the metrics eCommerce retailers keep a close eye on (or should keep an eye on). Why? Consider the chain of events that happens before the customer abandons the shopping cart.

1. Customer comes to your site instead of going to one of your competitor’s sites. Awesome, they know that you exist and they have selected you!
2. They find the items they want to buy. Awesome, you have exactly what they want.
3. They like the price and add the items to their shopping cart. Hurrah, it is wallet time!
4. They start the checkout process (I see them pulling their wallets out)

Then whoosh! all of a sudden they abandon you. You almost had their money, but in a flash they were gone. Given that it is a website, you don’t know who they were or how to contact them to understand why. All you know is that you just lost a sale.

So what can you do to improve your situation when faced with this? I propose that you pay close attention to “friction points” that cause the customer from not buying from you.

There are many eCommerce “friction points” that have been well documented, but you still see so many sites that make these mistakes.

1)   Form fatigue – every field on the form that you are asking the customer to fill out is a friction point. Especially, if you are asking for information such as fax number, address (especially if I am signing up for an email service), annual income (yes, I am so inclined to reveal this to a complete stranger) and the list could go on. Your marketing department will likely have justifications as to why each of these fields are needed, but you as a product manager must think from your customer’s perspective. Yes, marketing is important, but you have to find the right balance between your needs and the customer’s needs. After all, your marketing department is not the one paying you money to keep you in business.

2)   Required registration – If users don’t understand why it is needed and the value registration would provide them, they will flee in droves. I have seen this in person during focus groups and usability testing. Common reaction: “S***w this, I am out of here”

3)   Surprises – Don’t surprise them! Imagine that you as a customer gets to the end of the checkout process and the retailer springs a $15 shipping fee on you. How will you feel? Would’nt you abandon if you think the shipping fees is a rip-off?

However, there are a lot more friction points that certain verticals take advantage of or there are others that if solved can increase conversions. The classic example I always use is “mailing” – the old fashioned way where you have to deal with envelopes/boxes, stamps, post office

Let us first look at the example where the company is hoping and praying that you will not mail anything. The commonly used marketing gimmick of “Mail-in rebates”. Retailers offer discounts on products via mail-in rebates. The price after mail-in rebate looks very attractive while you are in the store or when shopping online. But these companies make you buy at the full amount and want you to send mail-in a flimsy card to get the rebate. They are banking on the fact that most customers will not mail it in because of the “friction points”  involved in filling out the long form, attaching all the required documentation and making sure they mail it within the specified time period. And they are pretty successful at it because research shows that 90%+ of customers don’t.

Now let us take another example, where it is paramount to the company that customers mail things in for it to be successful. I currently work at Gazelle.com where our customers trade-in their used electronics such as laptops, iPhones, Blackberries, cameras, camera lenses, gaming consoles, movies, video games etc. for cash. We sell the gadgets we buy via eBay, wholesale channels or recycle them responsibly all here in the United States. The process involves the following steps:

1)   You tell us about the model and the condition your gadget is in by answering a few questions on gazelle.com.

2)   We tell you right away what we will pay you if the gadget passes our inspection and matches the condition you told us in.

3)   You mail us the gadget, we pay for shipping.

4)   We pay you via the payment method you selected (check, Paypal, Amazon gift card etc.) after we complete the inspection within 10 business days.

We are experiencing explosive growth, but one of the “friction points” we always think of, is the act of our customers having to ship their gadgets to us. It does not matter if a million customers come to our website and tell us that they have a million items to sell us. Unless they actually put it in a box and mail it to us, it does not matter.

So here are ways we work hard to reduce this “friction point” of shipping:

1)   We always pay for shipping – we email you a pdf that has the packing slip and pre-paid shipping label.

2)   For many categories, we even send you a box free of charge so that you can use it for shipping.

3)   We keep you informed throughout the process once we receive your gadgets.

4)   We pay you as soon as we complete the inspection. In fact, if our inspection shows your gadget to be a better condition than you had told us, we pay you the higher trade-in value, no questions asked. In the event we find the gadget is in a worse condition than you had stated, we send you a revised offer and explain the reason for the reduced offer.

5)   We give you the choice of accepting this revised offer so that we can send you the payment or if you decline and want your gadget back, we ship it back to you free of charge.

Now if you happen to live or work near our office, you can even walk in with your trade (forget about boxes and shipping labels) and we will pay you on the spot.

Now these are the things we do today. Are we done yet, hell no!. We are always looking for new ways to further improve our processes such that we can eliminate the “shipping” friction point.

We continue working on finding economical ways to reduce these “friction points” so that we can stay in business and work on our vision to “change the way consumers consume.” When we still have a vast majority of electronic gadgets ending up in landfills and polluting the environment, we at Gazelle know that we still have a lot of work to do.

As product managers, it is important for us to realize that unless we reduce our customer’s friction points of doing business with us, we are not going to be successful. And the friction points may not always be related to the product, but it maybe within the ecosystem of your product – whether it is customer support, documentation, order management, sales support etc.

Thoughts? What are your customer’s friction points and what are you doing to solve them?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.

Image: Courtesy of carfullofpandas.com

Note: I had written this as a guest blog post last year on Subrata Majumdar’s blog called Confessions of a Digital Immigrant, that I am publishing here.

Is a software product manager needed during early stages of a startup? If yes, what should be his/her role,  given that everyone tends to wear multiple hats and the distinction between Product Management/Marketing and Architecture/Development is blurred. Is this a healthy cross-pollination or a disaster in the making?

I will offer my opinions on these questions drawing on my 13+ years of experience in the software industry and having played a role in the creation of successful products and utter failures.

1) Is a software product manager needed during early stages of a startup?

Yes, a software product manager is absolutely needed right from the early stages of a startup. A bunch of engineers can band together and write awesome software. But often, engineers fail to ask the fundamental questions – nothing against my development colleagues, they have enough to worry about to begin with.

1.    What problem does it solve?

2.    How many customers have the said problem?

3.    Are the customers willing to pay to solve the problem?

4.    Who is going to buy the darn thing and will they pay enough for us to be profitable?

5.    Does this solve the problem the way the customers expect it to work or do they have to change their ways?

It is a software product manager that will help a company to answer the above questions and make sure product development is aligned with customer problems. Only then will a company be able to create a business, sustain it and be successful.

Otherwise, you run into the infamous argument (I call it a trap) that I have heard over and over – if we build something, they will come. No – unless you have something they absolutely want at the price they want, they will NOT come. If the user experience does not save them time or money, they will keep solving the problem the old way because a) they do not have time to learn new ways and b) humans by nature are resistant to change.

There have been very successful products that created paradigm shifts, but more so because of the tremendous value and differentiation they offered the customers. For example, in mid 80’s, Pro/ENGINEER the 3D mechanical design software from PTC was the pioneer in creating this market segment by switching a lot of users from AutoCAD 2D design software to 3D. It was hard to use, it was expensive, it needed designers to completely switch their ways, but the design benefits were very obvious to those users that switched (and not to mention PTC’s very aggressive marketing and sales force). But paradigm shifts are rare. I am not suggesting that you do not innovate and create new ways to solve existing problems, but new ways should always have easily understood customer benefits. Otherwise, you will face adoption resistance.

You could also argue that one could launch a product and let the customer community take the role of helping you discover problems the product could solve. Yes and No. I would argue that it needs to solve one particular customer problem well enough to get noticed even by the early adopters. Unless you do this, no one is going to even consider buying/using your product. Unless this happens, no one is going to help you shape the future of the product to solve other problems it could potentially solve. I will draw an analogy – does anyone ever get out of the house and start driving hoping that you will end up somewhere nice by chance. Not very likely. But we are willing to take such a risk developing products, hoping that we will strike rich?

In this day and age of the internet and its free products, there are companies that have created free products that have sustained themselves for very long (Facebook and Twitter come to mind), but in the long run even these companies have to figure out ways to monetize their business to survive.

2) What should be a software product manager’s role in a startup given that everyone wears multiple hats and the distinction between Product Management/Marketing and Architecture/Development is blurred?

The roles of Product Management/Marketing are blurred primarily because the industry does not have consistent job descriptions for these roles. In some companies, Product Marketing does market sizing, segmentation, positioning and pricing decisions and Product Management figures out the customer problems in the selected segment and then works with engineering to make sure the right and usable product is being built. In other companies, all of this ends up with the software Product Manager and this is usually true during the early days of a startup.

But are there limits to what the product manager needs to do, such that he/she is not spread too thin? Yes, there are. I tend to use a very simple litmus test to determine activities in which a product manager must be involved – Does this activity help the product manager in listening to the market and making sure that the right and usable product is being built? If the answer is No, free up your time by getting it off your schedule.

I would especially shy away from getting involved in architectural and development related decisions for a very good reason. As a product manager, it is your role to think like a customer and then inform engineering what problems need to be solved and how. You can advise engineering in terms of customer expectations in terms of scalability and performance. But it should be engineering’s sole responsibility to figure out how to architect/design the product to solve the problems a product manager has identified. If you get involved in the latter, very quickly you are going to look at problems in terms of implementation details rather than from a customer’s perspective. Not a good idea.

Having said this, I will not hire a product manager if he/she is not ready to wear multiple (but relevant) hats even in a mature organization, leave alone a startup. Product manager’s role is one of the most cross-functional roles in an organization. Hence, by definition, such a role requires one to wear multiple hats, supporting sales, supporting marketing efforts, making sure the right product is being built by engineers and so on.

Thoughts? Comments? What have you learnt from your experience as to what works and what does not?

All products ship with one label – your brand label – IBM, Microsoft Office, HP Pavilion, whatever your company’s brand name is. That is all what your customer gets to see. No product/feature ships with the name of the person who came up with the idea. So it “was my idea” or it was “Tom’s idea” actually does not matter in the scheme of things. So anytime spend worrying about who came up with the idea instead of collectively trying to make the idea better for the customer is wasted time. Your customer really does not care. There are only two outcomes – the product is a winner or it sucks. All of “us” are going to be considered a bunch of heroes or a bunch of idiots. Which would you rather be? So if we focus only on the opinion that matters, that of the customer, we should all come out ahead. But often this is easier said than done, isn’t it?. Unfortunately, we are human. But let us try darn hard reminding ourselves and our team members that products/features don’t ship with the inventor’s name tag!

This week, I started my new job as Director of Product Management at Gazelle.com (aka Second Rotation Inc.) What do we do at Gazelle?

1. We allow consumers to get cash for their used electronic gadgets such as cell phones, GPS, laptops, camcorders, MP3 players and even ebook readers.
2. You can find out right on our site how much we will pay you and then if you accept our offer, we even pay for you to ship the item to us. If the item has no monetary value, we will even recycle it for you provided you send it along with some thing else that has a monetary value.
3. We then find new homes for these acquired items to other consumers in the secondary electronics market.

We thus prevent these electronic gadgets from ending up in landfills. Want to know more and see if you can get cash for your gadgets? Check us out at www.gazelle.com – want to see how we all of this happens inside gazelle? – check out the nice slideshow on Gazelle put together by the Wall Street Journal.

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the column on the right.

The results of the Massachusetts senatorial election this week to elect the replacement for the senate seat held by Ted Kennedy shocked the entire nation. A Republican named Scott Brown who not many people had heard about about as recently as a month back won the seat convincingly in a largely Democratic state. Ted Kennedy had held this seat for the last 46 years. As recently as Jan 1st, the Democratic candidate Martha Coakley was considered a shoo-in for winning the seat. But then she lost. The repercussions are large with Democrats losing the filibuster majority in the Senate and President Obama’s health reform in its current form nothing but dead. What an irony. Ted Kennedy had spend his whole life championing health care reform.

As a software product manager, I took away the following 4 lessons from this election:

1. It ain’t over ’til the fat lady sings – I am sure all the pollsters who advised Martha Coakley told her that she was a definite win. She did not run a hard campaign. In the corporate world, often times sales thinks that a deal is in the bag long before the deal has been signed. No, it is never done until the signature is on the contract.
2. There is no entitlement - Yes, the seat was held for 46 years by one of the legends in the senate. It is a largely democratic state. But none of this gives anyone an entitlement to a senate seat. You could be the incumbent, a highly entrenched software vendor in an enterprise, but this does not give you the entitlement that you will always win all the future deals. Companies switch vendors all the time. So in every deal, give your best fight as if your whole business depends on it. This is the only way you can guarantee a win. For the election, people send a clear message as to who are the decision makers. In your sales situations, don’t forget that the customer has the last word.
3. Keep the message simple - I don’t remember one thing that Martha Coakley said. But for Scott Brown, I know about him riding around 200,000 miles in his truck campaigning, his message that he is the 41st vote. I did not vote for him, but he kept the message simple and it resonated with the electorate. That is all that matters. Your customers do not know as much about your products/technology/company as much as you do nor do they care. But they know about their problems, their products, their business, their company much more than you ever will. So make it relevant to them and keep it simple, if you want to win.
4. Don’t forget the network effect – The election was for one senate seat, but it drew world’s attention. The impact has been earth shattering. In your sales situations, losing a customer may appear like losing just that – one customer. But in the social media age we live in, how many are going to find out and how many are you going to lose based on this one customer’s influence? On the flip side, it may sound like one new customer, but how many new customers will this help you win? I remember from my SolidWorks days that winning Halliburton was a huge deal for us. Because it helped us establish a beach head in the oil and gas vertical and since then, it helped us win so many large customers in that vertical. So be aware that every action you take may have a network effect – consider this before you act.

Thoughts?

Image: Courtesy of aphr.wordpress.com

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.

This is a continuation of my previous blog post of Software product manager’s first 30 days at a new job …..

Now that you are already settled into your new job and the first 45 days have gone by. You have done everything that was listed on the 30 day checklist. You have met with the stakeholders, they know who you are, you know the product, you are gaining momentum. Now what next? (BTW, in case you are wondering why I skipped the time period from 30-45 days, read on.)

It is hard to describe what the next steps need to be because it will depend on many factors such as organization structure, where the product is in its life cycle, your vertical etc. But here are 4 things I recommend you do during these 45-90 days to keep up the momentum. I think these 4 things apply no matter what product you are managing.

1. 90 day plan – If your boss and you have not already put a next 90 day plan, you put one together. Create a proposal on what you think you need to accomplish, where you need help from your boss etc. Then sit down with your boss, refine it and finalize it. This will speak volumes to your boss of your organizational skills, your ability to set goals etc. But then, make sure you follow them and get it done. Achievements and not goals are the only things that matter after everything is said and done.
2. Customer visits: Try to visit at least 5 current customers. If customer visits are not possible, try to make phone calls at the very least. If I am still not completely comfortable with the product/service by now and are nervous to engage with a customer, I try to go with someone else who may be visiting the customer. This could be a sales person, another product manager, customer support person etc. Here is what I typically tell these customers during these calls:
   1. I am new to the company (sets expectations that you are not an expert on your product yet)
   2. I introduce myself to them including explaining what my role is (believe it or not, many customers don’t understand what a product manager does, I also tell them that my call is not to sell them anything)
   3. I want to understand their business processes and where my product fits into their business process
   4. Understand why they chose to use my product or service?
   5. What do they like about us?
   6. Where do you think we fall short? Make sure that you set expectations that you cannot commit that these will be fixed. Remind them that you will get the information to the right people and that you are still a newbie.
   7. I want to build an ongoing relationship with them to make sure I continue to listen to their needs and painpoints, run future ideas by them to get their early feedback etc.
   8. I leave my direct phone number and email with them

   Write a report on what you heard from customers (good and bad) and send it to your product team and other stakeholders. This will help you build credibility within the organization that you are quickly getting up to speed and that you have started gathering real market data. In the future this credibility will help, because others won’t mistake your recommendations to be just your opinions but instead ones grounded in market facts.

3. Secure early wins in areas that are important to your boss and where you build credibility within your organization. But before you commit to do anything, get permission from your boss. While the idea is to start getting yourselves en-grained into the process, you also don’t want be the newbie to be assigned a task by someone because it is an unpopular task and a setup for failure. What you should be looking for are tasks where you can start making contributions that your boss and others in the company start recognizing you and getting to know you. Try to find tasks that others may not want to do – that is OK. The idea is to help the team win. This may be anything such as:
   1. helping putting together a customer presentation
   2. updating the product roadmap by incorporating the latest changes
   3. testing a new piece of functionality that has been implemented
   4. helping with usability testing on a new feature (helps you get in front of a customer, observe and listen to how they react to your product)
   5. providing your input on a small feature that is going to be implemented. Research how the feature needs to be implemented, write requirements document. Believe it or not, this will help you understand all the inner workings of your product – what it takes to make even simple changes.
   6. writing release notes for an upcoming new release
   7. helping fill out an RFP from a prospect etc.
4. Product demo – Call a meeting with your product team and anyone else who think can help you. Tell them that you would like to do a product demo to them to simulate a customer situation. Let them know that the whole point of the exercise is to gauge where you stand in terms of knowing your product in and out and also figure out gaps which you need to fill. This event is not because product managers will be demo jockies, but because you as a product manager must be able to demo your product in the event of a crunch.

Now why did I leave out the 30-45 day period. Only because I think to complete everything that was listed in the previous post will likely take you 45 days. Stakeholders will ask you to reschedule your 1 on 1 with them, you will run into hurdles such as getting accounts setup for all the tools you need to use etc. And if you don’t and you are rocking, I am sure your boss will give you new tasks to do that you had not planned for.

Thoughts?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.

Image: Courtesy of hamiltonbeach.com