Happy Friday!

Just a quick post to answer the question we sometimes get from prospective customers:

Is your Product Management Software compatible with Mac?

As a Mac user myself, I’m happy answer this question in the affirmative. YES, our Accompa Product Management Software is 100% compatible with Mac!

This is because our software is 100% cloud-based -and- 100% based on HTML and related standards. It is not dependent on 3rd party plugins like Flash, Java, etc. Nor is it dependent on browser features specific to Internet Explorer, etc.

As a result – you can now enjoy our product management software for Mac, without having to switch back and forth between Mac and Windows! Accompa is fully functional on both Windows and Mac – and on all major browsers: Firefox (my fav browser), Chrome, Safari, and Internet Explorer.

If your team has product managers who use a Mac like me, Accompa may be a good fit. To learn more and find out whether Accompa can indeed help your PM team – check out the product tour or request free trial.

Product Management Insights

Engineering teams at more and more companies are using some form of Agile development process. I’ve seen a lot of discussion on the internet on how Product Management (PM) teams can adapt to this Agile world.

PM teams at a lot of companies use our requirements software – so I also get questions from our customers about how best their product managers can work with their Agile development teams.

In this post, I’d like to share my evolving thoughts on this topic.

BTW – One of the questions that is often discussed on this topic is:

How can Product Management teams follow Agile process?

I believe this is the wrong question! I will explain why in this post too.

Agile is a Development Process

First things first. Let us review what exactly “Agile” is. As explained at the Agile Manifesto website, “Agile” is about “better ways of developing software” (emphasis mine).

Agile manifesto includes 4 items:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Development teams following various Agile processes (such as Scrum, XP, etc) follow this manifesto to develop software in a better way.

Product Management is NOT a Development Process

While “Agile” is a development process – “Product Management” is not a development process. While product managers (PMs) work closely with development teams, I believe the role of PMs is (or at least should be) very different than that of development teams.

PMs (should) primarily focus on:

• Understanding customer needs.
• Translating those needs into commercially successful products.
• Create product strategy and roadmap to meet customer needs – preferably better than competition.
• Prioritize items in the roadmap – preferably using ROI (return on investment).
• Create (or work with others such as BAs to create) requirements.
• Communicate requirements to development teams, and work with them to build the product.
• Work with marketing and sales teams to price, position, promote and sell the product – and achieve market success.

Product management should thus be focused on customer needs, product strategy, product roadmap, and prioritizing roadmap using ROI. All of this requires “Long Term” focus.

Product Manager vs Product Owner

“Product Owner” is a new role, recommended for Agile teams by Scrum Alliance. Product owners usually work with development teams and perform the following roles:

• Create, expand and/or prioritize user stories
• Manage sprint-level backlogs
• Communicate product vision
• Be the final authority representing customer interest

I believe “Product Owner” is (almost) a full-time member of development teams – whereas a “Product Manager” is not (or at least should not be).

“Product Owner” is mostly focused on the “Near Term”. On the other hand, a “Product Manager” is (or should be) mostly focused on the “Long Term” – as explained in the previous section.

BTW – At small companies, one person may play both roles. This is totally fine – but this does not mean both are the same role!

The Wrong Question – and the Right Question

As a result – I believe the question “How can Product Management teams follow Agile process?” is the wrong question. The right question is:

How can Product Management teams work better with Agile development teams?

I believe product management teams should focus on better ways of working with development teams that use Agile processes – rather than adopting “Agile” processes (such as Scrum, XP, etc) themselves.

In fact, a lot of successful companies (all the way from Fortune-500 companies to growing startups) do just this. How do I know you ask? They use our software to achieve this – and I’ve personally spoken with many of them, in depth, about this topic.

FYI: If you’d like to see whether our software can help your team too – check out the product tour or request free trial.

Product Management Insights

I often get the following question when chatting with friends and acquaintances who work at high-tech startups here in Silicon Valley:

Why can’t we manage requirements using bug trackers like Bugzilla and JIRA?

This is a great question, and my answer may surprise you – knowing that I work for Accompa, a company that makes a popular requirements management software!

Here’s my answer to this question…

Teams *Should* Use Bug Trackers for Requirements – Until They Grow Out of Them

Most companies start out managing requirements using Word or Excel documents, as these are readily available tools. When they grow out of such “flat file” documents, they switch to bug trackers like Bugzilla or JIRA – as such tools are also readily available at most companies.

Most teams find that bug trackers are a far better approach to managing requirements than “flat file” documents. In my opinion, if a team’s requirements management needs are fully met by bug trackers, they should just keep using them. This can be especially true for very small companies and brand new startups.

When You Grow Out of Bug Trackers – Try Out Requirements Management Tools

What we find from our customers (Fortune 500 companies to growing startups) is that they eventually grow out of bug trackers – i.e. bug trackers simply do not meet their requirements management needs any longer. This is when companies switch to requirements management tools like Accompa – and find that their needs are met in a far better fashion.

This is why I tell my friends and acquaintances at startups to keep using bug trackers as long as they fully meet their requirements needs. And graduate to requirements management tools when they grow out of bug trackers…

FYI: If your development team is using JIRA or Bugzilla, but you’d like your PM team to graduate to a dedicated requirements management tool – I have good news! Accompa now comes with pre-built integration to JIRA, Bugzilla and many other popular tools. To learn more about Accompa – check out the product tour or request free trial.

Product Management Insights

I read a nice blog post on the Harvard Business Review website by Rob Johnson who worked with Steve Jobs to create the wildly successful Apple Stores. The following quote caught my eye:

So the challenge for retailers isn’t “how do we mimic the Apple Store” or any other store that seems like a good model. It’s a very different problem, one that’s conceptually similar to what Steve Jobs faced with the iPhone. He didn’t ask, “How do we build a phone that can achieve a two percent market share?” He asked, “How do we reinvent the telephone?” In the same way, retailers shouldn’t be asking, “How do we create a store that’s going to do $15 million a year?” They should be asking, “How do we reinvent the store to enrich our customers’ lives?” (emphasis mine)

This is a great point, and is especially important for product managers building high-tech products to embrace.

Here’s why…

Product Management Should Focus on Enriching Customers’ Lives

At many companies, the primary focus of the Product Management team seems to be on metrics like market share, competitive comparisons, win/loss rate, etc – and not enough on adding true value to customers. While such focus may lead to short term benefits, I believe this is counter-productive over the long-term.

There are many other departments (such as Sales teams) who, I believe, are better suited to focus on short term metrics. Product Management teams, on the other hand, can add the most value by focusing on new ways to “enrich customers’ lives” by reinventing the status quo.

Product Management Insights

I recently came across a blog post by The Cranky Product Manager about product-line complexity. It’s an entertaining post. More importantly, it makes good points regarding the pitfalls of complexity. In this post, I will share my thoughts on this.

Product and product line complexity happens when we add too many features or when we add overly complex features. Often this happens over time as a product “matures”. It can also happen because of lack of rigor when writing requirements. When it happens, both your customers and your company suffer.

Here is a short list of… the negative impacts of complexity, followed by a few tips to help product management teams avoid product complexity.

Negative Impacts of Product Complexity

• Lost Customers/Revenue
  • You can lose a customer before they have a chance to look at your product or learn about your organization by overwhelming them with too many choices.
  • After the sale, if your product is complex and the learning curve too high, adoption will be low.
• Productivity/Internal Cost
  • Complex solutions often take more time and effort to design, code, test, and document. This results in higher initial costs both in time and dollars.
  • Complex solutions require more maintenance and support. They’ll have higher costs throughout the life of the product.
• Opportunity Costs
  • When everyone is dealing with product complexity, whether the product manager, engineering, sales or marketing, you have opportunity costs. Complexity can rob you of the time and effort that could have birthed a “game changer” idea or solution you never had time to think of.

4 Quick Tips for Product Management Teams to Avoid Product Complexity

• Set Simplicity as a Goal
  • First, everyone in the team needs to understand the value and goal of keeping the product simple. Simple does not mean “Less than enough”; it means “Just enough”.
• Empower Simplicity
  • Empower everyone in the team to speak up about complexity and to continuously look for opportunities to simplify solutions. Be rigorous. It will pay off in the long term.
• Redesign for Simplicity
  • Don’t be afraid to redesign when you realize something is overly complex.
  • Recently, I was 80% of the way through a requirement for a new feature when the VP of products, in response to a technical question said “This is too complicated. Start over and see what you can eliminate.” The result was a significantly less complex, and ultimately much better solution.
• Maintain Product Focus
  • Always ask yourself and the team if a desired feature is something that most of your customers will use regularly. Be rigorous in your assessment.
  • You may sometimes hear from prospects and customers that if the product just did “X” they would buy (insert large number here) licenses. The problem arises when feature “X” is not in alignment with requests from the vast majority of your customers. In such cases, offer an alternate solution or work-around, rather than adding the feature.

Those are my thoughts on this.

Product Management Insights

Recently I saw a question on LinkedIn:

Product Management or Product Marketing, who is responsible for messaging in the product to convert trial users to paying customers?

This is a great question, and is especially important for companies building SaaS applications.

Here is my opinion…

Well, before I share my opinion on who owns the “in-product” messaging, let me reiterate a thought I previously shared on this blog.

Product Management vs. Product Marketing – Two Departments or One?

I believe Product Management and Product Marketing should be just one department, rather than two separate departments. Such an arrangement offers several benefits – including making the question of this post completely unnecessary!

That said, I’m realistic and know that many mid-to-large companies have both departments. As a result, this question becomes very relevant, especially for companies building SaaS applications. How so?

Relevance for SaaS Product Management & Product Marketing

Many SaaS companies offer a free trial to prospective customers. This free trial is usually for a period of 14-30 days. For example, our company offers a 30-day trial for both of our SaaS applications – requirements management software and idea management software.

During the trial period, SaaS applications display/share “in-product” messaging intended to convert trial users to paying customers. This often includes educational material, “nag” screens, days left in trial, email reminders, etc.

Who Should Own “In-Product” Messaging?

When a company has two separate departments – i.e. Product Management & Product Marketing – I believe the “in-product” messaging should be owned by Product Marketing, with Product Management serving a consultant role. Here is why…

Even though the product itself is owned by Product Management, the “in-product” messaging is not really an integral part of the product. Rather, it is like any other messaging about the product – such as the website, brochure, etc. As a result, Product Marketing should have the ultimate ownership for it.

FYI: Another question that runs into similar debate is “Who owns requirements?”. While that discussion is beyond the scope of this post, I do have a related news:

Product Management and Product Marketing teams at more than 100 companies now manage their requirements using cloud-based requirements management software from Accompa. If you’d like to see whether Accompa can help your team too – check out the product tour or request free trial.

Product Management Insights

Just saw a nice blog post by Marty Cagan. If you are a:

• Director of Product Management
• VP of Product Management
• Or aspire to be one of the above (I think that should cover just about everybody in product management, don’t you think?!)

, then check out Marty’s post.

Having said that, there is one point about which I don’t fully agree with Marty. That point is…

I Really Prefer to Focus on Strengths

The one point in Marty’s article I don’t fully agree with is:
Identifying gaps & Creating development plans to fix weaknesses

I’m a big believer in the Marcus Buckingham school of thought when it comes to managing people – i.e. I really prefer to identify and emphasize their strengths, rather than identifying and fixing weaknesses (exception: fresh college grads with an open mind).

Basketball analogy: (since the playoffs are underway!)
If you’re coaching Carmelo Anthony who can’t/won’t defend or pass the ball – I think it’s far better to emphasize his strengths (one of the best offensive players in the world), than try to “fix” him by getting on his case about defense and passing.

How You Can Do So Too

If your company is of sufficient size, then there are usually many different types of projects/products – where product managers with different strengths can excel. One of the most important roles a Director or VP of Product Management can play here is – fit the right product manager to the right project/product.

If your company is a small startup, then someone else (hint: founders, execs) should cover the product manager’s area of weaknesses. If that’s not possible – the only viable option might be to get someone better.

Product Management Insights

Mark Suster (who has founded and built two successful software startups)  recently blogged about hiring at a startup. It’s an excellent post and got me thinking about hiring product managers at a startup.

From my experience of having built Product Management teams at two different successful startups, and having been an early member of the PM team at a third successful startup – I believe all of Mark’s points apply well to hiring product managers at a startup too.

Read on for my comments on how some of Mark’s points apply to hiring product managers at startups…

3 Tips for Hiring Product Managers at Startups

Mark makes 7 excellent points in his post – here are 3 of them, along with my comments on how they apply to hiring PMs at startups:

• Only hire “A” players:
  • At a startup, the product manager will very likely impact the work done by all of the engineers and sales reps.
  • So it’s even more important (than other individual contributor hires) that the PM hired is an “A” player.
• Don’t worry about exact “roles”:
  • Even if you hire someone with the title of “Product Manager”, he/she must be willing and able to play multiple roles at the startup. For example: PM, UI designer, QA tester, Technical writer, etc.
  • PMs who are specialists and do only one thing are not as valuable at startups as they are at mid-to-large companies.
• Attitude over Aptitude:
  • At a startup, a PM’s attitude is as important as (often more important than) his/her Aptitude.
  • As HP Jin, Founder/CEO at TeleNav used to tell us “At a startup, you are set up to fail. You must be able to succeed in spite of it”. This requires the right attitude – especially for a product manager, who has no “formal authority” yet is expected to make a major impact across the company.

For the full list of 7 points, including details and valuable tips, be sure to check out Mark Suster’s post…

Product Management Insights

The best companies (B2B) I’ve worked for during my career were highly innovative, and they continuously innovated. But the source of their innovation was not:

• Whiz-bang Technology
• Genius Personnel, or
• Competitive Research

What was the source, you ask? Well, the type of innovation those companies practiced was…

Customer-Driven Innovation

The most successful B2B companies I’ve worked for practiced Customer-Driven Innovation.

What do I mean by “customer-driven innovation”? I mean:

Innovation driven by a deep understanding of customer needs.

A deep understanding of: Not just what the customers asked for, but also why the customers asked for it. And the business problem customers were trying to solve, or the business objective they were trying to meet.

Advantages of Customer-Driven Innovation

I believe customer-driven innovation offers B2B companies several advantages, including:

• Higher odds of success: When your innovation is driven by actual customer needs, I believe your odds of success are much higher. When it’s driven by technology or competition, your odds of success are likely to be much lower – i.e. hit or miss.
• Can be systematized: The process of creating successful innovation based on customer needs can be systematized, whereas the process of relying on one or more people’s epiphanies or Eureka moments cannot be.
• Repeatable: This follows from the previous point. Once a process is systematized, it can be taught to others in the company and can be repeated.
• Scalable: When the innovation process is systematized and taught to others – it can be used not only to enhance existing products, but also to launch new products in the same market, in adjacent markets or even new markets. All of which leads to a business that can scale.

Product Management Insights

One of my friends is a newly minted Director of Product Management at a mid-stage startup in silicon valley. I met him for coffee yesterday and we were chatting about how his new job was going.

He has managed Engineering as well as Professional Services teams in the past, but this is his first time managing a Product Management team.

He told me he thought product manager interviews are easy to fake, and even unqualified candidates can easily fake a good performance during the interview. This got me thinking…

Majority of “Product Manager” Interviews I Went to Were Easy to Fake

During my career in product management, I’ve probably interviewed with about a dozen companies for the “Product Manager” position. Over the past 8 years, I’ve been hiring product managers as well.

Having been on both sides of the table, I have to agree with my friend. Almost every interview I had (as a candidate) for the product manager position were easy to fake. The questions were generic and were more the interviewer evaluating personality fit rather than testing for any specific skill-set or knowledge.

Tip I Borrowed from Engineering Interviews

On the other hand, most interviews for an engineer position are very specific and hard to fake. For example, when hiring a programmer, companies often give them a problem to solve and ask them to write code (or pseudo-code) during the interview.

Early in my career as the person hiring product managers, I adopted the same technique. I’ll give the Product Manager candidates a problem set and ask them to come up with short list of requirements, product positioning and UI wireframe – during the interview itself (approximately 90 minute interview).

It was surprising how many candidates with stellar resumes and excellent interview skills fell flat in this exercise. Equally surprising was how many candidates with average resumes and average interview skills shined during this exercise. I always hired the latter, not the former. The long-term results were quite good.

Tips for Interviewing Product Managers

Here then are my tips for your product manager interviews:

• Test for specific skills – such as the ability to create requirements, UI wireframes, product positioning, pricing, etc. Make it hard for a candidate to fake his way through the interview.
• While I’m a big believer in testing for specific skills, I’m not a big believer in “domain knowledge” or “industry specific” experience. I believe product managers with the right skill set can easily learn these in a short time.
• Ask for and thoroughly review the candidate’s portfolio – such as MRDs/PRDs, etc. Ask deep questions against her portfolio to understand her thought process.

I believe these tips can help you improve your success rate in hiring good product managers.

Product Management Insights