Le sigh!

This past Sunday, I had an interesting debate with a friend of my mine whom I’ll refer to as “Peter” in this article. Mainly because that is his real name.

Peter is the VP of R&D for a cloud-software company in southern California.

He told me (and I’m paraphrasing):

“Product Managers and Business Analysts are dying roles, because with Agile/Scrum there is no need for these roles any more. Soon these roles will be eliminated from most of the software companies.”

This statement annoyed the heck out of me. Hence the sigh at the beginning of this post.

Peter and I had a lively (but short) debate, we had to cut it short because we both have day jobs – which seep into weekends! I told him I will make a couple of blog posts to explain my take on this.

So, here is the first one for you, Peter! As I explained in this post, Agile is a “development” process – i.e. a process used by developers, to develop software.

As you know, Product Managers are *NOT* developers! Neither are Business Analysts! PMs and BAs play a different role – mainly focused on understanding customer needs, and translating those needs into clear requirements. These requirements are then used by developers to build the product – using agile, waterfall, spiral, or whatever software development process suits their fancy needs!

When I asked you who will define the details of what needs to be built, once PMs and BAs are history – you said something along the lines of:

“Product Owner or whoever. If no one is available, my developers can do it themselves as they are well-trained in Scrum.”

Please see this post for my take on how PMs are different from Product Owners.

And, I’d say about 80-90% of the developers I’ve worked with (whether Scrum-trained or not) have neither the interest nor the skill set to play PM and BA roles. If you ask developers to do it, I think:

1. Most of them will do a bad job – due to lack of interest and skill set, not lack of IQ.
2. And, they will be unhappy about having to do something completely unrelated to programming.

Anyways, I will stop here for now – as I’m running late on a bunch of tasks related to my day job, which includes building software for the “dying” roles of product managers and business analysts! Until next time…

Product Management Insights

A question our team sometimes gets from our prospective customers is:

Can Accompa software help me implement Pragmatic Marketing Framework™?

I will provide the answer to this question in this blog post.

Legal Disclaimer

Before I get to the answer, here’s the legal disclaimer. Why? We’re committed to respecting the trademarks and rights of others.

Pragmatic Marketing Framework is a trademark of Pragmatic Marketing, Inc. The owner of this blog – Accompa, Inc. – is NOT affiliated with the trademark owner in any way, shape, or form. We’re referring to this trademark in this post as per the “nominative fair use” doctrine of the U.S. trademark law.

So, Does Accompa Support This Framework?

Okay, let us take a look at this question.

If you’re reading this post, you’re probably aware that Accompa is a leading cloud-based software for product management teams. PM teams at more than 100 companies use Accompa to manage and collaborate on requirements efficiently.

While Accompa is NOT designed for, nor tied to any specific product management framework – it is designed to be extremely flexible. As a result of this flexibility – you can easily customize Accompa to implement almost any framework or methodology you’d like to implement.

• We’ve designed Accompa from the ground up to be flexible. You can easily customize it – in just a few clicks, right from your web browser! This helps you implement the framework of your choice.
• We keep this flexibility in mind for every new feature we implement – even though doing so takes a lot of additional time & resources.
• This flexibility is, in fact, the #2 reason given by our customers for choosing Accompa.

How Can I Use Accompa Software to Implement Pragmatic Marketing Framework?

Here’s how you can use Accompa to implement various aspects of Pragmatic Framework:

• Start with “Simple Mode” in Accompa – this will give you one object named “Requirements”.
• Then create custom objects  named:
  • Personas
  • Problems
  • Use Scenarios
• Now, you can track 4 types of requirements artifacts:
  • Requirements
  • Personas
  • Problems
  • Use Scenarios
• You can then customize the attributes you’d like to track for each of these 4 artifacts – using the custom fields feature in Accompa.
• Once you’ve done this – you can start entering requirements data under these artifacts, plus create relationships and dependencies between them!
• You can also slice and dice your data easily – such as:
  • List all requirements (or problems, or use scenarios) for a specific persona.
  • List all personas who need a specific requirement (or who experience a specific problem).
  • and so on…
• You can even create additional objects to track other pertinent data such as “Win/Loss Reports,” etc.
  • With our soon-to-be-released Salesforce.com™ integration, you can even automatically sync Win/Loss data from Salesforce.com into Accompa.

Can Accompa Fit Your Team’s Product Management Framework?

Now the big question! Can Accompa really fit your team’s choice of product management framework?

Honestly – there is only one way to know for sure! Apply for our 30-day free trial. If you’re approved, our team will provide you free support to help you customize Accompa to fit your needs & frameworks. You can then find out whether Accompa works for your team. Fair?

(Apply for 30-day free trial of Accompa, and find out whether Accompa can meet your PM framework needs)

Product Management Insights

I’m making a quick post today to define the term MRD – Market Requirements Document. I’m often asked about it, now I can just point everyone to this blog post!

Definition of MRD: Market Requirements Document

MRD is a document that is usually written by a Product Marketing Manager or a Product Manager. This document defines the high-level market requirements for a product or project. (See Types of Software Requirements for a list of various types of requirements).

An MRD usually contains the following information:

• Executive Summary
• Vision
• Target Market
• Competitive Positioning
• List of Features
  • Derived from market needs
  • Prioritized based on ROI

The following teams usually “consume” (i.e. read) the MRD:

• Business Analysis
• Engineering
• UI design
• Marketing
• Sales
• Executives

Don’t make this mistake!
Sometimes, people refer to MRD as “Marketing Requirements Document” (note the extra “ing”). Perhaps this is because it comes from the “Marketing” department. But “Market Requirements Document” is a better definition, as this is a document that contains market requirements.

MRD vs PRD

At many companies, the MRD is used to create another document – the Product Requirements Document (PRD). PRD is then used by Engineering and QA teams to build the product.

At some companies MRD and PRD are combined into one document. In this scenario, the MRD also contains the following information:

• Use Cases (Functional Requirements)
• Non-functional Requirements (Such as Security, Performance, Scalability, etc)
• Requirements are also prioritized

Further reading: I wrote a post on my old blog that covers the distinction between MRD and PRD in more detail. Plus, check out the following post for a list of various types of requirements documents. This will help me avoid repeating that info here in a redundant and repetitive fashion!

FYI: Accompa Requirements Management Software can help you automatically create MRD and PRD for your project. This can save you a lot of time over manually creating them. Check out product tour or request free trial.

Product Management Insights

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.

So, 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 dedicated 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