Posts

Posted on

Starting on the right foot in your new job as a product manager

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

Posted on

3 mistakes to avoid in a Product Manager Resume

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
Posted on

Customer Visits – Do’s and Don’ts

I attended the Product Camp Boston over the weekend and shared what I have learnt doing over 300 Customer Visits in 10 countries (US, Canada, Japan, UK, Germany, Netherlands, India, China, South Korea, Taiwan).

Customer visits can be the best qualitative method to learn the most about your customers/prospects – stuff you will not learn from surveying them. But this is only if you do them right. Based on experience doing 300 of them in 10 different countries, I would like to share what has worked and what has not.

Here are the slides I used.

Posted on

I am looking to hire a Product Manager

I am looking to hire a Product Manager who has minimum 4 years of experience doing software product management (mostly consumer) to join my team doing product management for International products at Care.com. Details below. You MUST have 4+ years of experience to be considered. If you or anyone you know is interested, please send me your resume to gshenoy (at} care [d o t) com. 

The international group is small (total of 7), follows an agile development process and is very fast paced. We launched in the UK last month and will be launching in other countries very soon.

Product Manager based in Waltham, MA

Care.com is seeking a highly motivated individual to join its International Product Management team in the position of Product Manager. The individual will be responsible for defining, prioritizing, and overseeing the implementation of features and functionality of Care.com‘s international websites. The ideal candidate must have previous experience developing product requirements for an online, consumer service. In addition, the candidate must be able to effectively manage cross-functional teams of stakeholders throughout the organization.

Specific Duties/Responsibilities:

  • Ownership of product requirements for Care.com’s online product offerings for international markets. This includes the requirements gathering process, requirements documentation, and the ongoing maintenance of requirements as the business context evolves.
  • Working directly with stakeholders throughout the company to ensure that a successful product is delivered.
  • Working with business owners to understand and document the product requirements.
  • Working with engineers to communicate product requirements, make trade-offs, and oversee the product implementation and testing process.
  • Working with marketing to understand marketing plans and strategy and ensure the site and reporting platform support those plans.
  • Working with the member care team to ensure that product support concerns are addressed in the product requirements.
  • Working with the finance team to ensure that any revenue generated from the product is accounted for correctly.
  • Driving cross-functional teams to deliver a product which is on-time and in compliance with the product requirements.
  • Assist Director of Product Management in creation of product roadmap for international products.

Skills/Experience Requirements:

  • 4+ years of product management experience REQUIRED.
  • Experience working for a company/organization that develops and runs an online service, preferably a consumer-oriented service.
  • Experience working directly with customers in doing market research and usability testing.
  • Experience writing product requirements documents and functional requirements documents. This includes experience developing wireframes using tools such as Balsamiq or other similar tools.
  • An understanding of Information Architecture and a passion for defining a highly-usable online experience.
  • Demonstrated ability to manage cross-functional teams, solve complex problems, and produce high-quality results.
  • Knowledge of and experience with reporting requirements of an online product.
  • Experience working in an agile development environment.
  • Ability to roll up the sleeves and work in a fast-paced, start-up environment.
  • Excellent oral and written communication skills.
  • Ability to work independently and in a team environment.
  • Willing to travel internationally as required to meet with customers (travel expected to be less than 5%)

Education/Other Pre-Requisites:

  • BA/BS degree in engineering or related field.
  • Knowledge of German, French or any other languages considered a plus.

 

Posted on

Market Sizing – Quick and Dirty Techniques

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.

Posted on

Meet the Product Manager

What do you do when you’re a product manager (for web applications and tools) who has started a new job, assigned to an existing team who are just about to embark on the development of a range of new products and product features? We’ll whatever the correct answer is, this is what I have started to do. The first step I took was to review the situation and give the team the opportunity to voice their opinion.


I soon realized in my first week in my new role as product manager that there was plenty of scope to improve a number of aspects of the product development process. We are currently using a hybrid of Scrum and waterfall (the logic behind this will form the basis of a later blog post). I waited for all the team members’ to return from their holidays before holding a team meeting that I tagged “meet the product manager”.

I introduced myself as a product manager who ‘eats their own dog food’ – in other words I’m an active user of online tools, blogging platforms, social media and networking sites.

I also took the opportunity to let them know the things (from a professional perspective) that I’m passionate about:
  • All things to do with Product Management/Marketing.
  • Working with engineering/development teams and cross functional teams.
  • Agile software development particularly, scrum.
  • Creating strategy and visions and driving them through all the stages to completion.
The things that I’m not passionate about – in fact the things that we should, as a team, avoid at all cost. See the familiar cartoon strip below.


I followed this with a case study: comparing two redesign projects that I was the  product manager for.  One using waterfall which had a shared test resource and the other using scrum with a dedicated test resource. The results were alarming. The waterfall project took +60% more man hours and went live with 100 plus small and medium bugs, whilst the redesign, that was developed using scrum, went live with 4 known minor bugs. I used this experience not only to demonstrate my active involvement in scrum but to illustrate the type of transformational product development we can achieve if we work closely together and use the scrum frame work wisely.



I highlighted that as the scrum product owner I would initially be spending a lot of my time and energy  over the next 4 to 8 weeks, developing: in conjunction with the business owners, commercial owners and other senior stakeholders, the product strategy, product roadmap and release plan - the end result being a backlog with at least 6 to 18 months worth of work in it. Naturally the backlog would need constant grooming as coarse grain items become high priority.  I would also naturally be on hand on a day to day basis to support the team and work with the scrum master to remove impediments

I then handed out post-it notes and ask the team to write on each note their likes and dislikes and also to introduce themselves e.g. where they've previously worked, what they’re passionate about, hobbies and interests…

One of the key messages message that the scrum training drummed home to me when I was first trained on the scrum framework was that scrum does not solve problems it only identifies them. However scrum, if practiced appropriately, will make change and tracking and tracking the results of change much easier. Here are the top three likes and dislikes the developers highlighted.

Dislikes:
  1. No dedicated  full time test analyst, not using  automated test tools; the team failing to carry out unit testing and code reviews.
  2. Changing requirements /scope creep causing work to be either wasted or having to be reworked.
  3. Opinions of the team not always being embraced when it comes to decisions on functionality.

Likes:
  1. Knowledge sharing among the team – experience and ideas are traded freely.
  2. The fact that we use scrum/agile – the team liked all aspects of scrum especially the ability to select tasks on a daily basis.
  3. Product Manager being part of the team as opposed to being absent (note complement was aimed at the interim contract product manager cum technical team leader).
My job as product owner aka product manager in conjunction with the scrum master aka technical team lead – is to ensure that the team is empowered to change those things that we have the power to change. Understand and communicate the reasoning behind the things that we can’t change and be patient with the things that will take time to change.

I said to at the beginning of this blog post that the first thing was to review the situation and give the team the opportunity to share their thoughts – the second thing I’ll do (and publish the results in a future blog post) is to survey the team to see how mature they are with regards to practicing scrum.
Posted on

Combining Classical and Agile Product Management

I was asked to present, at an interview, on how I see the role of the product manager working in an agile scrum environment. The key areas that I highlighted were:
  • Scope and responsibilities of the product manager in scrum
  • Typical product management activities in scrum
  • A typical day in the life of the agile product manager
  • The agile product management framework
  • A case study – the benefits
See full presentation below.
However since the interview/presentation and starting in the new role the company has decided to change direction and combine waterfall with scrum. The idea is that we start off in waterfall mode move into scrum and then finish in waterfall.

Since joining the first thing I noticed was that the current scrum team is being led (as opposed to the team self managing itself) by a contract technical team lead cum product manager who spends part of his time being the scrum master and part being a business analysis.

In order to bring clarity and set expectations from the start I went about working with the head of development and head of product management to define, at a real granular level, the scope of the product manager aka product owner and that of the scrum master who is currently the technical team lead.
The end result was a list of 90+ activities: starting off with documenting the product vision and ending in the release of a sprint. The activities combine classical product management with agile product management – a real hybrid taking the best of both worlds. The roles and responsibilities matrix was signed off by both heads – now the journey begins.

Next week I meet with the development in order to explore the journey we’ll take together in developing the products allocated to us.
Posted on

Product Management interview question on strategy and tactics

I was being interviewed for a Product Managers position by a Chief Operating Officer (COO) who used to do the job that I was interviewing for. The company has adopted and really embraced scrum so naturally expects the Product Manager to take on many of the Product Owners responsibilities. I ask the COO to broadly split the role down into three aspects. His reply was:
1. Vision and Strategy
2. Execution and delivery
3. Stakeholder management and collaboration

I jotted the above answer down on my note pad. He then asked me “what percentage of my time I think I would spend on each of the above three activities.” I paused for a second – gathered my thoughts and jotted figures next to each one:

1. Vision and Strategy – 20%
2. Execution and delivery – 40%
3. Stakeholder management and collaboration – 40%

Fortunately for me he agreed.

I often hear and read of Product Managers and Product Marketing Managers stressing at their yearly appraisals that they get too bogged down with the tactical and have no time for the strategic and visionary part of the job. The problem is that if you don’t use it (the visionary and strategic thinking) then your loose it. Amy C Edmondson in HBR puts it this way:

“Execution is difficult to sustain – not because people get tired of working hard, but because the managerial mindset-set that enables efficient execution inhibits employees’ ability to learn and innovate. A focus on getting things done, and done right, crowds out the experimentation and reflection vital to sustainable success”. Harvard Business Review July – Aug 08
Correct implementation of the Scrum process aims to solve the problem where the Product Managers/ Product Owners gets burned out due to “efficient execution” and a sharp focus of “getting things done” and “done right”. A Product Manager/Owner knows the cycles of the team and can therefore plan his/her work in advance. The key is to ensure that there is a well balanced Scrum team. I like the way Marty Cagan puts it:
“You will need product managers to represent the needs of your target users and lead the product discovery effort. You probably already have project managers (aka Scrum masters), but if not, you’ll need product managers too; just don’t make the mistake of trying to hire one person to cover project management and product management.” (italics supplied)
It’s important for each product person to deliberately carve out time for themselves to do activities that will be the catalysed for strategic and visionary thinking. Such activities would include (but not limited to): visiting customers, researching the marketing and competition, discussions with the development team on the latest and greatest technologies as well as discussions on how existing technologies can be used in an innovative way, looking at how other industries (current and past) have solved problems. When I led a team of product managers – I gave them one day a month to spend out of the office in order to research what ever they wanted – all I asked in return was for a one line explaining what they had discovered. The key is not to get distracted by too many tactical things – hence the one day out of the office: Tom Grant Forrester analysts expressed it this way:
“Product Managers need to focus on the strategic inbound tasks instead of being distracted by too many tactical demands… companies need to hire or cultivate product managers who have the skills and experiences necessary to produce high-quality product management deliverables – not something that anyone can do with out training”
Tom continues by identifying the benefits of ensuring that Product Managers spend quality time on vision and strategy activities:
“Companies that make these product management reforms will be more competitive and better able to use product management deliverables to make better strategic decisions.
In short it’s a win: win situation for both you and the company. So we product people need to take the time to develop ourselves and companies need to give us the time and ensure we have the band width to do it.
Posted on

Interview with a Pure Product Manager

In this audio interview I speak with the author of the blog Purist Product Management: Aziz Musa. I had the opportunity to work with Aziz for a year at Reed Business Information and found him to be an inspirational and focussed product manager. During the interview I review Aziz’s:

  • academic and professional background before becoming a Product Manager;
  • his experiences at Last Minute.com;
  • the strategic element of the job;
  • how best to interact with the customers;
  • the optimum number of products a typical Product Manager should manage;
  • how to keep up with the latest trends and technologies and
  • the top 3 attributes needed to enter the Product Management arena.