Software Product Manager by Gopal Shenoy

A fundamental product management principle that I live by is Customer obsession! To me, everything starts with the customer and the painful problems they have that they expect my product to solve. I have always coached the product teams I have led using this mantra.

No one in the office will ever open their wallets, pull out a credit card and buy our product*. The people who will do that live outside this office. So spend time with them to deeply understand their problems so that they will buy!.

What we have inside the office are opinions (often strong) or solutions proposed by customers. These are nothing but hypotheses which need to be validated by product managers by engaging with customers who have these problems. You as a product manager, need to ask the “Why” to understand the problem and if these are indeed painful problems for the customer that they are worth solving to deliver customer value and also a positive impact to our business.

The only way that I know of to do this effectively be via constant interviews/visits with your customers or prospects. There is never a state where you know enough about your customers because their needs change, new technologies arrive solving problems in new unique ways and in some cases creating new sets of problems or your competitors make moves. To stay abreast of all these changes, you need to continuously engage with your customers at least on a bi-weekly basis. A good start would be to talk to at least 1 customer/prospect a week.

I don’t buy the excuse of lack of time. Not having time is a prioritization problem. If product managers are expected to be the voice of the customer, there is nothing more important than being in constant touch with your customers.

If you are not doing this or if you are outsourcing this completely to sales, professional services or customer support teams, then you are going to have difficulty in making your customers open their wallets and pull out their credit cards and buy your products. These teams can definitely be great channels for customer/industry intel, but you need to have a direct channel of your own to customers/prospects.

Eventually every business needs their customers to open their wallets and pull out their credit cards!

Thoughts? If you like this, please share it with your network of product managers.

*- Agreed there are some exceptions if your company makes hardware like Peloton or Hydrow or electronic gadgets.

Often times, product teams say that they are data driven or express an interest to become data-driven. But what does “data-driven” actually mean?

Data-driven means you rely on data (facts) than personal opinion or intuition to make informed decisions. One of my favorite quotes is the following:

“If we have data, let’s look at the data. If all we have are opinions, let’s go with mine.

Jim Barksdale, former CEO of Netscape

Data is a product manager’s friend. It allows you to trump strongly held opinions of internal stakeholders and in some cases also allay fears of your stakeholders. Data builds credibility of a Product Manager because you are stating facts and not your personal opinions.

However, a common pitfall I have seen is the way in which data is interpreted. It is not uncommon for two team members to analyze the same data and arrive at two different conclusions. The root cause for this often ends up to be the lack of a common data glossary. A data glossary nails down very specific definitions for terms you use in your analytics. For example, if you loosely use the term “visitors”, which of the following does it mean?

Number of visitors to your site for a given timeframe

or

Number of first time visitors on your site

or

Number of visitors who are not registered members on your site?

As you can see, a simple term called “visitors” could be interpreted in multiple ways causing confusion, lack of trust in all of the data and eventually loss of your credibility as a Product Manager.

So how do you go about creating a data-driven product culture in your organization? Here are the 5 steps I recommend product teams use to get to this goal.

Step 1: Define Success Metrics

For every new product or feature, the product development team led by the Product Manager should define the questions they would ask themselves to determine if the product or feature is a success. I highly recommend that as a group, you write these down so that the team can come up with questions with very detailed specificity to avoid issues described in the definition of “visitors” above.

Step 2: Define data that needs to be captured

Once you have agreed on the questions you should answer to determine success, you should now determine what data should be collected to answer these questions. I would recommend you write down very specific definitions for each of these data elements.

Step 3: Define Data Source

Once you have determined what the success metrics are and what data needs to be captured, determine where the data will be stored. Don’t assume this is obvious, because in my experience if this is not well planned upfront, some data could end up in tools such as Google Analytics and some in say internal databases. The disparate data sources will then make it difficult to get a unified view of the product or feature performance.

Step 4: Pull data

Define how, when and who will do the data pull once the product or feature is launched. Would this be done by merely querying the database directly or will you be creating visualizations in the BI tool such as Looker or Tableau that you may be using in your company? I would encourage you to keep it simple, especially if you do rapid experimentation via A/B testing or iterative development because usually a lot of the experiments fail and you do not want to build out visualizations to only discard them if the experiments did not move the needle in the direction you were hoping for.

Step 5: Generate insights

All the instrumentation and data capture does not mean anything, unless product teams religiously look at the data and generate insights from them to see if you accomplished the success you set out to achieve. So create a cadence where each of the product manager presents the insights learnt from the last set of experiments or released features. Such a cadence will help create a learning culture not just in the product management team but in the product development team as a whole.

It is imperative that the Product Leadership team is held responsible and accountable to provide the structure necessary to coach and mentor the product organization to build a data driven culture. The leadership team should be measured against this goal by the senior leadership. One way for Product Leadership to facilitate this is to reserve time in weekly or bi-weekly product team meetings to review data and insights generated from the last set of experiments or most recently released features.

Thoughts? How have you setup your product teams to be data driven?

Over the last few months, I have been interviewing for a software product management leadership position – Director or VP level. The search took over 6 months (discounting the lull between Thanksgiving and New Year when hiring activity is understandably very low).  Over the course of my 25+ year career, I have also reviewed hundreds of resumes, interviewed hundreds of candidates and been part of hiring decision for 10s of candidates, some of them as a hiring manager. Given my experience as a job seeker and a hiring manager, here are 10 job search and interview tips that I would like to share.

Yes, we are living through unprecedented times because of Covid-19. Unemployment has gone through the roof, many companies have laid off people (how to survive a layoff) or have gone on a hiring freeze. There are still companies hiring, but you should plan for the hiring process to be slow and very selective. Candidate experience was terrible to begin with, expect it only to get worse because now companies have less recruiting resources, less number of open positions and a ton of job applications. But it is what it is, it is not something you can control. This time will pass and to get a job when companies start hiring again, you have to start seeding now. Train your mind for this job search to be a marathon that could last a few months. Then if it happens sooner, you will feel great. If it does not, it would have been what you expected. But everyday tell yourselves this “Today, I am one day closer to my next job“. This is a fact and it could be your biggest motivator during the job search which sometimes can be exhausting. It did for me.

Resume

1. Your resume must focus on outcomes and not activities: 99% of resumes I have reviewed as a hiring manager or been asked to review by job seekers, are resumes which are a list of activities. For example, a bullet point reads “Identified new product opportunities via market research”. This tells me nothing about the business outcome that resulted from this activity. Companies want to hire employees that will help them achieve business outcomes. So your resume should speak to the outcomes you accomplished in each of your jobs. So if you rephrase the above to be outcome based, it could read something like “Conducted market research that resulted in identifying 5 new product opportunities. Presented the business case for these opportunities and launched 3 new product features that resulted in 12% increase in product adoption within 6 months of launch” – that is 100X better to read as a hiring manager – You now stand out and I want to talk to you. Remember that when I am doing a 10 sec scan of your resume, numbers catch my attention because they stand out in an ocean of text. So make your resume as quantitative as you can (but never lie – believe me this happens more than you think) and be prepared to explain these numbers in more detail if asked.
2. Resume file format: Always send your resume as a PDF file. If you are applying via an external recruiter, they will ask for a Word document so that they can put their information on top of your resume before sending it to the hiring manager. But for all other cases, use a pdf file for the following three reasons:
   1. A lot of users now use Macs. Many of them do not use Microsoft Office. So if you send them a resume as a Microsoft Word file, they have to do a lot of work just to view it.
   2. Pdf file is portable, looks professional and printing it is guaranteed to be WYSIWYG. If you send your resume as a Word file, the format is not guaranteed to be portable between Windows and a Mac.
   3. Your resume is your product brochure and represents your brand. No one should be able to make any modifications to this brochure. You own it, period. No one can modify your resume if you send it in as a pdf file.

Applying for the job

1. NEVER EVER apply for a job via the company’s website: If you do, expect to hear nothing or get some automated reply. As well, not apply. Here is an example of what actually happened in my search. Since I did not know anyone in this company, I decided to apply via their careers page. Two days later, I found a way to network my way in to an executive at this company. He connected me to the internal recruiter who immediately called me and we spoke over the phone for 30 min. He said he was going to discuss with the team and get back to me. About 10 min later, I got an automated reply that I was not a good fit and that my resume will be kept in their database. I was perplexed. I forwarded this email to the recruiter to find out what was going on. He asked me to ignore it and wondered who sent it – very likely an auto responder. Go figure! Your #1 goal is to get your resume seen by the hiring manager. Stated in other words, your goal is to cut in long line of job applicants and get in front of the line. Period. So how do you do this?
2. You MUST network your way in: You need to find your way into the company via your network (assuming you have built one, if not start building one now). You have to figure out a way to get introduced to the hiring manager or higher up by someone in your network that is well known to the person. (A blog post on how to effectively use LinkedIn during your job search is coming soon, so stay tuned).
3. Provide a short blurb to the person who will introduce you to their connection in the company: Let us say I am in your network and I am connected to the hiring manager or someone else in the company you are applying to. I agree to make an intro because my connection is strong. Don’t just send your resume and ask for an intro. Also send me a short blurb (one or two paragraphs) that I could wordsmith to include in my intro email. I may know you very well, but writing something from scratch is high friction and I want to introduce you well. So help me help you by providing me starting material that shines the best possible light on you.

During the Interview

1. Be prepared with an elevator pitch: The first question I always ask any candidate I am interviewing is the same – “Can you please give me your elevator pitch? and you have two minutes”. The answer to this question tells me a lot about you – your communication skills – are you capable of highlighting your skills and qualifications in a short amount of time and how all of this is relevant to the job you are applying for. You should nail this! This is your chance to make the best impression. You should nail it such that I want to know more. However, don’t make it pompous, be modest. Tell me how your experience is highly relevant to the job you are applying for and how you are the candidate that the company should hire.
2. Be prepared for behavioral questions: I like case studies, I love when interviewers ask me how I have handled specific situations in the past or how I will solve certain problems. I see them as an opportunity to showcase my skills. But it is difficult to think of best responses on the fly, so you need to anticipate them and prepare for them. Amazon is well known to do this as all their interviews have questions based on their leadership principles. There are a lot of good articles on the web on how to answer behavioral questions. I specifically like the one by Interview Genie. Create a document that has answers for as many behavioral questions as you can think of and review this document before every interview. Your answers must be genuine and you should be prepared to discuss them in depth if you get asked for more details. You cannot do this if you make something up just for the sake of answering the question. If asked a question during the interview that stumps you, it is perfectly fine to pause, reflect and even say that you will need more time to think about it than giving a less thoughtful answer.
3. Ask questions: I respect those candidates that have a lot of questions for me. This is an indicator of their interest in the job, in the company. This is your golden opportunity to show the hiring manager how you think, how you do your research or gather information. For example, if you are a software product manager and are applying for a product management position, I expect you to ask me questions that will help you understand the product management landscape in the company. Interviews should be a two way exchange between you and the company. Good companies will treat interviews this way. They should be able to gather enough information about you to see if you are a fit for the job and you in turn should be able to gather enough information about them to make sure this is where you want to work for the foreseeable future.
4. Ask if there are any concerns you could address and about the next steps: At the end of each of my interviews, I ask the interviewer if they have any open questions or concerns about my candidacy that I could address now. I am not asking them for their decision, but for an opportunity to address anything not discussed that could influence their decision. I ask this while thanking them for their time and do it a very genuine and professional manner. I do it with a smile. I also ask the last interviewer about the next steps and when I should expect to hear back and from whom.

After the interview

Send a thank you email: After the interview is over, send a thank you email to each of the interviewers. Thank them for their time to meet with you and refresh their memory of why you are the best candidate for the job. You want to do this the same day as the interview when everything is fresh in their memory. In the email, also mention how you look forward to hearing about the next steps from whoever was told will get back to you. This reminds them of the promise that they have made. Sending this thank you email does not guarantee you anything, but it will never hurt and it is the right thing to do as a professional.

Thoughts? Do you agree with these tips? Any other tips you would add to this list?

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

Please spread the word via your twitter or Facebook accounts. Thanks in advance.

Related Posts:

1. Ten job hunting tips for a product manager
2. Job Hunting Cheat Sheet
3. Eight traits of good hiring managers

From the time product management has been around, there is a notion that to be effective, product managers should behave like CEOs for their product. A belief that the successful product managers have the power to make decisions for their product like CEOs do for a company. Others can provide all the input they want, but the final decision should be left in the hands of the product manager. In my career of 20+ years having worked in many software companies in the Boston area, startups to large companies, this is furthest from the truth – I have never seen a product manager having the final authority to make critical product decisions like CEOs have. The CEO has the final authority for making critical decisions for a company. The notion that product managers lead by “influence” and not “authority” is absolutely true and this by very nature indicates that product managers are not CEOs. No one reports directly to a product manager unlike a CEO. This held true even when I was a product management exec – I could choose to exercise making a final decision with my direct reports, but usually not one that spans across the organization.

So if a product manager is not a CEO, are they anything that starts with a “C”? I say Yes – successful product managers are “Chief Information Officers” or “Chief Influential Officers” of their products – the product’s CIOs instead.

Like a CEO, a product manager needs to work with every external and internal constituency that touches their product – customers, industry analysts, partners, executives, sales, marketing, legal, customer support, order management, engineering, QA, you name it. From all these interactions, the product manager gathers a 360-degree view of the environment their product needs to be successful in. They become experts in “all information” that is related to their product – information related to competitors, sales, product performance, product issues, customer support issues, the list goes on. Product manager becomes the central point for not only collecting this information but also in ensuring that the right information is communicated to the right people in the organization.

It is having the latest and complete product information that gives the influential authority for the product manager to influence their cross functional team and in guiding them to make the right decisions for their products. More trust you build up in the organization as the “go to person” for the product information, more influential you become as a product manager. More time you are spending time outside the building gathering information about the people who will buy your products, more influential you become inside your own organization.

One can argue that even CEOs do not make all the decisions but lead their team to make the right decisions. True, but let us not forget that the CEO indeed has the authority to make a “my way or the highway” decision which product managers never do. Hence the big difference in my opinion.

So let us not lull ourselves to believe that we are CEOs of our products, but instead call ourselves the CIOs and work hard to become the best product CIOs we could ever be.

Do you agree? If not, let me know through comments. If you agree, I would appreciate if you share this with your product management network.

 

 

You all have likely heard the term FOMO – “Fear of Missing Out” – the fear that makes us buy products/services because everyone else is doing it and for the fear of missing out on something that others are getting out of it. A fear that has been proven to move products – people wanting stuff that is short demand (“ONLY 5 SEATS LEFT”) or has a sense of urgency (“20% off only TODAY”) or one driven by social proof (“all my competitors are using the software, so I should use it too”). The fear that drives users from mere window shoppers to instant buyers.  In the technology adoption cycle made famous by Gordon Moore in the book “Crossing the Chasm“, this fear moves the late majority to buy your product or service. But this is a fear that is experienced on the buying cycle – one experienced by your customers that makes them want to buy your product/service.

However, a more important fear that needs to exist in every company is the “Fear of Missing Touch” (Thank you Steli Efti for introducing me to this term at the Growth Marketing Conference in NYC yesterday). Without this fear within the walls of your offices, you have a very low probability of developing any product/service that will generate FOMO within your target market. So what exactly is the Fear of Missing Touch?

Fear of Missing Touch is the fear of not being in close touch with your target users that you don’t have a very good understanding of your target user’s pain points, needs and challenges. It is the fear that you are not leaving your office (where btw, none of your target users live) enough number of times to “spend time in the wild with the natives”.

It does not matter how many internal opinions are held within your office about what users want, unless you as a product manager is spending time outside the building listening to users and understanding what problems keep them awake so much, that they are willing to pay for a solution, you do not stand creating a product/service that will create FOMO. Don’t fall into the trap of not doing this because you hear stories of “Apple does not do this” or “Facebook did not do this” because they are mere exceptions led by exceptional one-in-million-leaders than the norm. Your chances of being an Apple or Facebook in winning is the same as winning the lottery. The business world is littered with more corpses of failed companies than successes.

Being in CONSTANT touch with your target customers does not guarantee product success, but not doing it guarantees failure.

It sounds very obvious right? But more and more people I talk to, it is apparent that everyone realizes that it needs to be done but is never executed on – it is like exercising. Some of the reasons I have heard for not doing it are the following:

1. Our founders have talked with target users before they started the company.
2. We all belong to the target users, so our needs are the user’s needs
3. We do a lot of A/B testing
4. We pay close attention to our competition
5. We have talked about it, but we have not been able to find <insert some excuse here> (time, money, motivation, ….)

I believe the main reason for not getting started is inertia. There is a feeling that you have to visit a lot of customers before it would be useful – not true. So here are three action items that you could use to get started, overcoming that inertia.

1. Set a goal of visiting just “ONE” customer a month (3/quarter). Once you get used to it and start seeing the benefits, up that to 5 customers a quarter.
2. Plan well in advance and send a calendar invite to the customer such that now you have an external commitment (to someone not in your office)
3. Visit that customer and send a report of what you learned to everyone. Or present at the company meeting to create awareness that you are visiting real people who will pay real money to buy your product/service. Invite others to join you on your next visit.

Trust me, you will be amazed at what you learn, how eye opening it would be for you if you do it right. If you want to know, how to do it right, read my previous post on “Customer visits – dos and don’ts“.

A word of caution – visiting target customers needs to be a continuous endeavor because customer needs change over time. There is never a state where you will ever understand everything you need to about your target customers.

Do you agree? If yes, please share this post with others in your network. Thank you.

 

As software product managers, we often deal with cross-functional issues from time to time such as projects that fall behind schedule and now risk making a release, creative designs not ready for implementation, serious production issues that require immediate swats to be released etc. When such problems crop up, keeping your cross-functional team including your management team updated with the latest information is of paramount important. You can take two approaches to communication when such “fires” arise:

1. Try to gather as much information as possible before you communicate so that you can include all the details of the problem and how you are going to fix it or
2. Communicate immediately acknowledging there is a problem without revealing the seriousness of the problem and details of how you are going to fix it.

When substantial time is needed to gather data to understand the impact and quantify the size of the problem, I always prefer the latter. In an emergency, it is important to acknowledge that you are aware of the problem and to communicate the message “we are on top of it”. This way everyone (especially your senior management) know about the problem and can rest assured that folks are actively looking into it. Then, once you have gathered more information follow up with the details, options to fix the problem and the recommended solution. Instead, if you wait until you have all the information and good amount of time goes by, someone is going to find out, things get miscommunicated and you could spend more time trying to set things right.

Relate this to when tragedies strike – there is always a “first responder” team that appears on the scene immediately. Their job is to arrive first at the scene and take charge of the scene and start the data gathering process. As a product manager, you should be your team’s leader and part of the first responder team. On-time communication with the whole team is one way to gain respect and make you the go-to-person on your team.

Thoughts? Your experiences?

Posts you may also like:

B2C vs B2B product management – 16 differences

Product demo experience – 3 key learnings

3 sources for competitive analysis

 

If you are a product manager thinking about your next career move or someone looking to move into product management, this is THE book you should read and have as your reference.  I have been doing product management for many years and I found the book so resourceful. Gayle Laakmann McDowell and Jackie Bavaro have done a great job covering everything from the definition of a product manager role (remember that different companies have different definitions of what we do), how to transition from a non-PM role to a PM role, how to write a cover letter and resume that gets looked at to potential questions (behavioral, case studies, analytical problem solving) that you could be asked in a PM interview. They have interviewed product managers in companies such as Google, Twitter, Airbnb and Microsoft asking them about their day-day to activities and also senior Product Leaders as to how they have managed their careers.

It is written so well that it is a very easy read. The chapter I loved the most in the book was the one on “Estimation questions” where different examples such as “how many tennis balls can fit into an apartment” are worked out. The only chapter I have not read in the book is the one on “Coding questions”. This is only because I believe that Product Manager’s focus should be on the “Which” and “What” and not the “How”. It is our job to discover the customer problems, figure out “which” market problems are worth solving and “what” the solutions should look like from a User experience perspective. It is engineering’s job to figure out “how” they are going to develop the identified solution. But the chapter does not take anything away from the book.

I am confident that this book can end up to one of the best investments you could make if you are thinking about switching or finding a PM job. I strongly recommend it.

Here is a link to the book on Amazon: Cracking the PM Interview: How to Land a Product Manager Job in Technology

This is the most frequent question I get from readers of this blog. Folks who currently are developers, QA engineers, sales professionals, customer support specialists have all asked me this question. I have written how you could start making the move to product management.

But here is a course that is now available from udemy. It is a 33-Video Lecture Course called, “Skillsets to Shift Your Career to Product Management,” is intended for beginning technology entrepreneurs, and for technology professionals with no background in marketing and product management. The course is narrated by Raj Karamchedu, a Silicon Valley technology business executive with over 19 years of experience in the markets of wireless, mobile, semiconductors, software and hardware. He is currently a co-founder of a boootstrapped Silicon Valley-based startup. Previously he was at Legend Silicon (an Intel Capital-funded fabless startup) with two hats, Vice president of Product Management and Chief Operating Officer.

To get more information on the course and to get the 77% discount (offered to readers of this blog), click on the link below.

https://www.udemy.com/productmanagement/?couponCode=gopahshenoy

So you have landed an interview for a software product manager position. You are excited! You show up for the interview and the interview is a bust. You do not get the job. Causes? Having interviewed many product managers, who looked very promising on the resume and ended up being disappointing during the interview, I have compiled the patterns I have seen as “7 Cardinal Sins”. This can also be considered as general tips for any position that you are interviewing for.

1. You hardly know anything about the company – I have had at least two instances where the candidate told me that s/he was hoping that I would explain what we do, our business model etc during the phone screen. Surprised? Think it is not possible? I was too until I heard this. Good thing this happened on a phone screen.
2. You do not know the job description/responsibilities in and out – If you don’t know the job description, why did you even apply? How did you figure out that your skills match what the company is looking for? The way a hiring manager can figure this out is by asking the question – “Why do you want to work for us?” or “Why should we hire you?” – These questions should be slam dunk for you if you are prepared, you can show case how much you know about the company, what you bring to the table that relates to the job description and your past successes and accomplishments that are relevant to the job. I have heard lame answers such as “Recruiter called me about this job and hence submitted my resume” or “You guys called me and wanted to talk to me.” Come on, while that may be true, you need to still do a sales job – you need to sell the product you have – “YOU”!
3. You do not have an elevator pitch – Same as the above, but if the interviewer asks the question – tell me about yourself, try to hit the ball out of the park. Relate your experiences that are relevant to the job. Sell, sell, sell! Your elevator pitch should be 2-3 min max. Give an overview that piques the interest of the interviewer that they want to know more.
4. You don’t know anything about the people you are going to interview you – You need to ask for the interview schedule before you get there. Then do the research – where have these folks worked at? Use LinkedIn. Do you and them have common connections? What questions can you anticipate given their background?
5. You do not have questions for the interviewers – when asked if you have any questions, you say No. It is quite possible that towards the tail end of an interview schedule that your questions may have been answered. But instead of a terse No, mention that you had many questions about X, Y and Z that you have asked the previous interviewers. Give everyone a window into your preparation. Ask questions that gives you a deeper understanding of the problems that they are looking to solve by making this hire, the organizational structure, decision making process etc. Ask the same question to multiple people and see if you get a consistent answer.
6. You have not anticipated questions or prepped for the interview – Research sites such as glassdoor.com to see what questions get asked in interviews at the company. Ask your contact what a typical interview looks like? Do they have a problem solving round where you are asked to solve a given problem? Practice doing a problem solving round before hand to get your thoughts together. It is hard to think on your feet when you are under pressure at the interview. So play through such a session before hand so that you can come up with a strategy of tackling it in the real session.
7. You lie on the resume – Believe it or not, this happens. If you get caught, not only will you not get the job but your reputation and integrity will be tarnished. In the world we live in, word travels fast. The tech world is highly networked, so don’t take a risk. I had one instance where a product manager claimed that he came up with a pricing strategy – when I asked him to explain it, I was told that he put it on the resume just to make it look well rounded. He admitted that he does not have experience with pricing. End of the interview, right there and then! I am not going to hire you as a PM and put you in front of customers if I cannot trust you. Never, ever lie on your resume.

Image: Courtesy of smallbusiness.yahoo.com

Should it be the state of product development, the next release, the next sprint? Should it be what keeps the company executives awake? Should it be the competitors? While some of these should indeed keep a product manager awake, the most important thing that should keep him/her awake should be what keeps customers awake. Customers have problems today that are real pain points. They are struggling to solve them using current means and are hoping that someone will solve them. They are willing to pay someone to solve these problems for them. This is what product managers should focus on and spend most of their energies. If you do this, everything else should follow. If you do not do this, then all of the other things tend to happen – your execs tend to stay awake, you start worrying about competitors, your sales start to shrink, you start worrying about hitting the numbers etc. So focus on the only thing that really matters – understand better what keeps your customers awake and solve them via your products – existing or new.

Thoughts? Please share them via comments.

It has been months since my last blog post. Call it laziness, lethargy, procrastination, sudden lack of confidence in my writing skills – every one of these had something to do with it. I used to tell myself that I had to do it. But never did it.

Last night, I was teaching my 9 nine year old daughter Navya how to compute the area of shapes. I was teaching her how to break the shape into rectangles and squares, calculate the area of each and then add them up. Suddenly, it dawned on me as to how I could break down this wall of not blogging.

It is simple – “10 minutes” and “Now”. I even have this written down on my monitor at work. When something feels too big and I have trouble getting started, I try breaking it down into steps each of which would take 10 minutes. And then I start doing them NOW. Believe it or not, it has been working and a proof point is this blog post. I just opened WordPress and started writing.

Try it for yourself. Whether you are a software product manager procrastinating on starting a requirements doc for a complex feature or you are a painter wanting to start a painting, break it down into “10 minute” chunks and start on it “Now”.

10 minutes get over fast and before you realize you are 30 minutes into it. The sense of accomplishment suddenly carries you forward. Agile development methodology is built on this core principle of breaking things down, building fast and shipping often.

Do you agree? Thoughts, comments?

Image: Courtesy of digitalminimalism.com

In an agile development process, you typically launch new features into production every 2-3 weeks. Before launch, it is important to ensure that all stakeholders get to know about the new features to be released. It is especially important for Customer Support, Training, Translators, Sales etc. to get to know these new features before customers get their hands on them. I have found the best way to do this is via a sprint demo. When I have organized these demos, here are three guidelines I have followed:

1. All key stakeholders have been invited – marketing, sales, product, customer support, qa, …..
2. The demo is held a couple of days before the release – stakeholders should have some time to react to the new features and also engineering – in case there are small changes that need to be made (textual changes or other very minor changes).
3. The demo is done by engineering. This is very key for me. Engineers toil hard to get everything done and it is their work that is being shown in the demo. Given this, they are the best ones to show case what they have built. It also ensures that everything to be released is completed before these demoes.

What are your experiences? How do you do your sprint demos?

 

In the past, I have written what a new software product manager should plan do in the first 30 days on a new job to be successful. If you are planning to start on the right foot at a new job, a key thing you need to understand is constraints. Especially in a startup, during early days when things are move lightening fast, shortcuts are the norm because of constraints. There is not enough money, people and most importantly time. You are trying to put your MVP (minimum viable product) out there, get early success to build upon that there are not enough hours in the day to do things better than you are doing now. 

So if you are a new product manager who walks into such an environment, the last thing you want to do is to start by criticizing how bad things are, how best practices are not being followed etc. Instead, spend the time to understand the reasons why things are the way they are. 9 times out of 10, the folks that have been there are not stupid to have done what they have done. The team will be very appreciative if someone takes the time to appreciate what they have done under the constraints they had. This will help you build the relationships you need to build to be successful in the long run. I am not suggesting that you be disingenuous and praise something when everyone around you knows it is a pile of shiitake.

You have been hired for a reason. It is probably because things have not been rosy and the company needs a direction. But before you start to rock the cart, first find the reason for the current madness.

Another occasion where understanding constraints becomes valuable is when you are making a business case for something. Sell the idea first (before you ask for resources), make sure there is buy-in and then outline the constraints that will need to be resolved if the idea needs to succeed. This could be asking for more people or funding.

Thoughts? Do you agree? What can you share from your experiences?

Image: Courtesy of scmep.org

I have been reviewing tens of resumes lately as I have been looking to hire a product manager in my group at Care.com. Here are some patterns that I have noticed that makes me to quickly move on to the next resume:

1. Buzzwords: When I read “Builds and manages relationship with customers to smooth transition from legacy, fragmented business processes and systems to streamlined global product development processes enabled by enterprise technology implementation that improve efficiency of new product delivery and sustaining engineering“, I have no idea what you are talking about and I move on very quickly to the next resume.
2. No quantitative metrics: If I see no metrics or results achieved based on what you have done, I get no sense of whether your efforts were successful or not. Instead of saying “Launched a customer visit program for direct reports”, add more meat and metrics. Tell me what happened as a result. Instead, it is more useful to read something along the lines of “Developed an on-site customer visit program for direct reports that resulted in 200 visits/year. Improved understanding of customer product design needs resulted in launch of 5 new products in 2 years for the machine design and consumer design vertical segments.” It gives me context and also a better understanding of your accomplishments. However, never make things up, hiring managers will be able to sniff things out very easily. Trust me, I have seen candidates lie on their resume and it has come out within 5 minutes into the interview.
3. No white space: Your resume is so full of text with minimal spacing, I as a reader have trouble focusing on something in your resume. It becomes a lot harder to read your resume. Presentation matters, readability matters. You want to stand out, make it easier for the hiring manager to read. Ask yourself this question – “Does my resume highlight my key achievements that will make the hiring manager want to pick up the phone and call me?” You do not have to put in everything you have ever done in your resume, what you want are your key achievements. The nitty gritty details can come in during the interview (if you think it is relevant to mention them). A good friend of mine, who has been a VP of marketing at many companies gave me a good rule of thumb – “1 page of resume for every decade of your experience”.

Thoughts? Comments? What are your experiences as a hiring manager?

Related articles:

1. 10 job hunting tips for a product manager
2. 8 traits of good managers
3. 7 tips to survive a layoff

This post is a guest blog post by Ilya Mirman, former VP of Marketing at VMTurbo, CilkArts (acquired by Intel), Interactive SuperComputing (acquired by Microsoft) and SolidWorks Corporation. Ilya is currently an advisor to many startups in the Boston area.

I was 9 years old when my father taught me how to estimate the height of a building using my thumb and simple geometry.  As engineers we are taught estimating techniques – in school, and by colleagues and mentors.  Quick-and-dirty assessments are indispensable as we engineer new products, and they’re just as critical for product managers exploring new markets and products.

Being able to quickly size a market is quite handy at several points in a product’s life cycle.  I am not talking about achieving the third decimal point of accuracy at a 95% confidence level; rather, I am talking about being able to know within, say, a factor of two or four what the opportunity might be.  Here’s just a few of the situations I’ve seen where roughly sizing an opportunity helped lead to a better decision:

• What is the market opportunity for Product X?  This is useful not just for go/no-go decisions, but also for what might be the right way to bring a product to market.  For example, a line extension that can appeal to 15% of your existing user base might be a very attractive new add-on for your company to introduce; though it may not, for example, warrant a spin-out or significant engineering diversion.
• What is the right funding and development path for New Idea X?  A new idea may be worthwhile, regardless of whether the opportunity it represents is $5M, $50M, or $500M.  But it sure might be helpful to have a clue as to which it might be!  If it’s $5M, it might be an interesting lifestyle business; if it’s $50M, it might be an interesting company for a couple angel investors to help get off the ground; whereas at $500M and up, it may be worthy of a venture capital investment and more aggressive development and go-to-market plans.
• Which user persona to target for the first release of Product X?  Often, a product might appeal to a couple different user types.  But rather than engineering the “gray sneaker” (when half the users actually want black, and the other half want white), it may be better to figure out which segment represents a better opportunity, and really optimize the product for them.

There’s no one “right” way to do market sizing, and in fact it’s often useful to triangulate using multiple approaches, to increase your confidence that you’re in the ballpark.  Here’s a couple examples.

Top-Down: The Filter Approach

The approach here is to identify a key metric that’s driving the opportunity, and the key assumptions / reduction filters to zero in on your addressable market. One of my start-ups was Interactive Supercomputing (a venture-backed MIT spin-off acquired by Microsoft).  Our software connected engineering desktop applications – such as MATLAB® or Python – and parallel servers, to solve large and complex numerical problems that can’t be solved with a desktop computer.

The market for high performance computers (also known as “HPC servers,” or “parallel servers”) was large and reasonably well-known – hundreds of thousands of servers sold annually.  There is a broad set of diverse applications and usage scenarios for HPCs, so the big question for us was, how many of them could benefit from our software?  Here are the three primary filters we identified:

1. Fraction of servers to run custom applications: The software running on these servers falls into 2 categories: it is either an existing software application; OR it is a newly developed application, currently being prototyped on a desktop tool.  Our software was suited for the latter scenario (enabling a much quicker path going from desktop prototype to deployment on a server).  Our research suggested that roughly half the servers purchased every year were for running existing apps, and half were for custom apps.  This 50% was therefore a constant filter in our model.
2. Desktop Language Support:  The first filter helps us identify the servers running new custom apps.  But that would be an overestimate, because our software was not able to help every one of the custom app developers.  Turns out that a second important filter is: which desktop tool or language is used to prototype the application.  Our initial product supported MATLAB, which according to our research was used to prototype ~25% of the custom HPC apps.  Over the following 3 years, we planned on introducing support for Python and R, expanding the addressable market to 50% of the custom HPC apps.
3. Product fit: The third and final filter was product fit.  Our software did not support all domains and applications equally well – for example, we were great for signal processing, but not genetic algorithms.  We broke down the numerical methods into about 10 domains, identified our sweet spots, guesstimated which ones we’ll strengthen over time, and felt that a reasonable model might be to grow this filter from 25% to 40% over 4 years.

Here’s the resulting model – we start from the universe of servers sold in the HPC space, and zero in on the footprint of ones we can address well.  Because two of the filters grow over time, as does the absolute number of servers shipped, the market grows rapidly:
(Note: I’m glossing over a couple details here, for clarity.  First is the connection between number of servers and the dollars spent.  And second, the fact that in addition to new servers modeled here, there is an installed base which is approximately 3 times larger, though less of them are available for new custom applications, and are typically not being sold to by the channel we were betting on.)

Bottom-Up Estimate

In the bottom-up approach, rather than starting with some total and filtering it to the relevant fraction, we do a bit of the opposite: identify the segments, to build up the total market opportunity.
At my next start-up Cilk Arts (a venture-backed MIT spin-off acquired by Intel), our mission was to provide the easiest, quickest, and most reliable way to optimize application performance on multicore processors.  Our software consisted of developer tools, and a runtime system.  We had hundreds of conversations with a broad set of organizations looking to make their applications run faster on the new generation of microprocessors from Intel and AMD.  We saw a large variety in terms of product fit, how many applications they develop, size of their user base, and what they may spend.

So to size the market, we identified the key segments, and estimated the key variables:

• Number of firms in each segment: through web searches and other data we actually compiled a list of many of these;
• Number of apps developed per year;
• Product fit:  Fraction of their apps we could accelerate (we had better performance in some sectors, and less of a fit for others);
• Estimate of value for each app based on conversations with hundreds of prospects.

My sense is that it was less important to know whether $480M was “right” and more important to quickly figure out that it was neither a billion-dollar opportunity, nor merely a $100M market (where the leader might garner a ~20% share).

Conclusion

Because there is no one source of info is that reliable or complete, it’s better to use multiple approaches to zero in on a good estimate.  Try to identify metrics that correlate with usage or size of the problem – possible sources of data include government databases, relevant publications’ reader studies, commercial databases, competitors.

What approaches have YOU used to estimate market opportunity?  We’d love to hear from you.