End User Validation

 It is difficult to design a product feature purely based on user feedback.

Customer Validation of Requirements

 Validating the requirements and assumptions with customers are important.  However, we need to consider the follow situations:

Project Prioritization

 I like to use the top down allocation based on our strategic intent as it is really representing who we are and what we would like to be.  It is a judgement and not based on feedback of customers.

Standup dynamic

If a standup is for one person to review all project status, the standup  will get long and for those three minutes when the review and the project owner is in discussion and the rest of team is idle.  When this is happening, I think that the best practice is to split the meeting to multiple separate standup meetings.

The About Page

To let the customer know which version of the software they are using, you can include the About page.

Some of the information is specific to the installation.

• Name of the Software
• Version Number
• Type of License

It is a good practice to include the following as well:

Use UI Mockup to drive the UI development

Using the UI mockup to drive the UI development is a very nice thing to do.

A UI mockup tool, like invision, provides many benefits to the UI development:

https://www.invisionapp.com

Review: Aha

Aha demonstrates how a cloud apps works.  It is a requirement tracking software.  It has the integration to JIRA.

It manages the lifecycle before the requirements come to development in JIRA as a user story.



Releases are created for managing the target delivery for a specific deadline.  A release has a start date and an end date.
 https://support.aha.io/hc/en-us/articles/201226575

Releases are draw in a Gantt chart, called Releases Roadmap. The visualization using a Gantt chart is very powerful tool.  
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are created as containers of user stories.
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are added to Releases.  Or more specifically, User stories from master features are added to releases.  When you view the user stories, you can optionally view the major features of that release, before drilling into the details to view individual user stories.

Dashboard Personalization Requriements

Dashboard Level

• The dashboard components by default shown on the dashboard should be relevant to the roles of the users.
• The dashboard components available to a user should be relevant to the roles of the users.
• You should be able to turn on and off of components on a personalized view of a dashboard.
• You should be able to reorder the components shown on the dashboard.  Reordering includes Move Up, Move Down,  Move Left, Move Right, Sharing the horizontal spaces among components, etc.
• Arranging components within a dashboard should be an end user personalization function, not just a dashboard designer function.

Component Level

• A Tabular view of the data is the most commonly seen component.
• You should be able to add additional relevant fields that you are interested.  The IT or the vendor provided dashboard may define the relevant fields that are available, but as an end user, you should be able to hide and show (some) individual fields. 
• For getting extra space for showing data, you should be able to remove the unwanted or not so useful fields.
• You should be able to customize the width of the column displayed as part of user personalization.
• You should be able to reorder the fields within a table

Almost all contents should be predefined by vendor managed dashboard and there should not be a need for any organization to hire "BI developer" to build dashboard.

NetSuite Expereince

Not very intuitive to use.

Expereince about Dashboard:

1. I cannot customize how many purchasing orders I would like to see myself after I login.
2. I cannot customize what fields I would like to see.






3. Can't remove the region not applicable to me







4. Can't see invoices, which are more relevant to me

MVP Trap and RAT (Riskiest Assumption and Test)

Recently I had a conversation with our new product management VP.   It was a very interesting and enlightening talk.

A lot of time, the MVP is being misused or inappropriately applied.

Oracle Bug Status Codes and the Process

Found the bug status codes used by Oracle:

http://www.oracle.com/us/corporate/acquisitions/hyperion/bugstatusdescription-072226.pdf

I think that it is a sophisticated system and represents accumulated knowledge over time at Oracle.

Here are the processes I followed to use this system.

Handling bugs in scrum process

This is an interesting topic about how to manage and prioritize the maintenance efforts in the scrum process.

Modern Product Documentation

Here are requirements from user and product interaction perspectives:

• We should not require people to download docs from somewhere else.  Links to docs should be available within the product.  PDF is fine but context sensitive contents are better.
• Use videos to demonstrate How-Tos.  Again, links should be available within the product
• Show Release Note directly with the product
• Allow the users to directly enter a support case within the product
• Allow the users to provide suggestions directly from the product
• A small News&Update - directly communicate to your users

This is the modern software should be and I just saw one!!

Idea, Discussion, Directions are not Enhancement Requests

A software enhancement request should be clear on what the feature will look like.

We do not need to define the solution and design yet, but we need enough information to work on them.

• Use Case - How the users will use the feature.  Who are those users?  When will the users need this feature?
• Justification - Why do you need it?  What happen if you do not have this?  Is there a workaround available?

Sometime, the request is too specific and does not include why.   We should not let a single customer/user define the product.  Even a request that is already defined specifically may need to be analyzed.

An idea may need to broken down into smaller pieces in order to be implemented.  The idea, the direction of the products should be captured separately from enhancement requests.

Product Management Roles

There is a good discussion in Linkedin Product Management group:

Why you became a product manager? or why you want to be a product manager?

Here is my view:

Using a meetup group as a marketing channel for your new products

I recently attended several meetup in the bay area.

I feel that the meetup group is a great marketing channel for startup to increase the acknowledgement of their offerings and contributions to the society. It attracts a much focus groups who has the interests in the product and many of them could become the early adopters in the early stage of the product lifecyle.

I still remembered seeing a similar Show and Tell meeting I attended probably more than ten year ago, about a product called web logic server. After several years later, this product become a dominate application server and acquired by Oracle.

I think that the startup, especially, the one which provide the development tool or development platform, should consider creating or sponsoring meetup events.

How to measure the product success?

You may have multiple product lines.How you measure their success?
You can have a simple metrics to measure how much revenue they are bringing into the company.

The way how we measure and evaluate the performance can change the behaviors.

Customer Orientation vs Competitor Orientation

This is a very old topic. I first touch this topic while I was in college. I have always keeping this topic in my mind.

First, this is what I think about Competitor Orientation -

You only need to be better than others. As long as your customer do not have any other choice, you can be the king and do whatever you want.

And, Customer Orientation -

Customer is the king. You should try your best to satisfy your customer' need.

Microsoft Project 2007 SDK

Microsoft provides the software development kits for developers to learn the Microsoft Project 2007 platform. It includes the information about how to integrate and extend the Project Server 2007.

Microsoft Project update the data to the reporting database (RDB) whenever you publish the project. The update from the Microsoft Project to the reporting database is at a per project, ad hoc basis. You do not need to schedule a ETL process to run over night.

It provides 14 OLAP Cube for custom reporting. The data from the reporting database will be further pushed into the OLAP cube, the same architecture as their prior release.

Business Requirement and Product Requirement

Are these two separate requirement documents? Some people believe that there is no differece between these two documents. I feel that we should separate these as two separate deliverables.

The business requirement document is sometimes referred as the marketing requirement document (MRD). It discusses the requirements at a very high level from a business perspective. It describes the problem that need to be resolved, the market opportunity, and sometimes the competitor offerings. It justifies if a development project should be initiated. The business requirement document is not tie to any given development release and should avoid using the product specific terms. Sometimes the requirements are described in a such neutral way that you cannot tell which module or applications will be impacted. Actually, the business requirements is more like a RFP from some prospects. It is a user view of the solution.

The product requirement document is sometime referred as the product requirement specification or functional specification. It describes the expected functionality from a product. It is an outcome from the requirement analysis process. It interprets the business requirements by mapping and describing them using the product terminology. It is the document to communicate the business requirement to the product stakeholders. A product requirement document should be written with a product release in mind although not all features identified need to be scoped in. The key point is that the detail scoping decision can be made based on the product requirement document. It is the product requirement document identifies the scope of a development project. In the PMBOK, the product requirement document can be regarded as the scope statement for initiating a development project. It defines the features and is the product view of the solution.

At some stage, the product requirement should be baselined for functional design. It should be subject to the change control process for scope control. Scope creeping can thus be avoid. However, it worth mentioning that the requirement analysis is a iteration process. You should not be too rigid on changing the product requirement during design phase. You should not feel hesitate to contact customers to clarify the requirement.