18. Why product managers are important?

Excerpt from another blog

"Good business analysis helps you make sure you build the right thing, at the right time, for the right reasons. By focusing on an organization's business objectives, tracing those to a viable solution with the necessary set of features, and then tracing further to detailed requirements, Business Analysts ensure that the organization's efforts are focused on the right things (features and requirements) for the right reasons (business objectives). In this economy, no company has the luxury to "build one to throw away" or even "fix it in release two." We all have to get it right the first time, and that's exactly what business analysis lets you do."

Though what Mike states in above post is true that in hard economic times organization can't afford to build and ship the unwanted product, I could substitute the role of business analyst with a product manager in above excerpt . (Though, in a non-product based, custom IT department organization, business analysts do have to wear the hat of a product manager).

A skilled product manager is equipped with powers to filter incoming demands, translate them into detailed product requirements, prioritize them for upcoming releases, and align with organization's vision and objectives.

Additionally, this fuziness of roles between a product manager and business analysts in especially dominant in asian market even in product based companies.

From another post,

I’ll be brought into a company and they often don’t have product managers or user experience designers – they generally do have project managers, andmaybe some form of “business analyst,” and of course IT developers, and they all usually report into a CIO. Sometimes I even find that the company has been outsourcing “the website” to external agencies to design and run.

Compared to a inhouse/custom IT solution, a consumer product requires higher standard of user experience in terms of performance, availability and ressilience, and product management techniques need to be applied to make sure the software doesn't fail.

17. Off topic: Checklist of a good enterprise software Part 2

A few weeks back, I wrote a post on good quality software. As expected, the list was not exhaustive. There are more than 60 parameters which a product manager should mention before the software is ready for production use in enterprise market.

In nutshell, based on the FURPS design, non-functional requirements fall into following category

1. Usability
2. Reliability
3. Performance
4. Security

The following questions will help product managers in generating a check list of non-functional requirements.

PS: I found a good post emphasizing the need for checklists. Here it is.

Usability:

1. Is the UI consistent with different locales? eg. can it verify addresses and zip codes according to regions? Does database schema support multiple locales?
   
2. How simple is server installation process?
   
3. How simple is client installation process?
   
4. Can I automate deployment of client application on large number of machines?
   
5. Is the uninstallation clean and removing all entries from file system and registry?
   
6. How accessible is documentation?
   
7. Is it easy to use according to user's profile?
   
8. What if multiple users are using the application concurrently?
   
9. Is it data locked effectively to avoid corruption, but is not over locked to hinder usability?
10. Can I update the server first without impacting the users?
    
11. Can I make sure the user's machine will be updated before they can access the server?
12. Can I import my data from application I am currently using?
    
13. Can I export the data to other applications I will be using? Are the security policies also migrated with the data?

Reliability

1. What is level of application availability required?
   
2. For a typical server, is application logic separate from data?
   
3. What if the database server crashed?
   
4. Is there a redundant data server available?
   
5. Is data available through attached through SAN or LAN?
   
6. Is there any need to rollback to some point in history if there is a virus attack or application bug?
   
7. What is our data snapshot policy?
   
8. What is the cost (time, resource) to restore a snapshot?
   
9. What happens to the new data that was entered while we restored the older snapshot?
   
10. Or, was the application down at that time? Or, will be lose the new data?
    
11. What if the entire data center power tripped?
    
12. Is another data center required to resume operations?
    
13. How much time will it take to resume operations?
    
14. Do we need to make application distributed so that users won't notice any power tripping?
15. What about application servers?
    
16. Does the server run on virtual servers?
    
17. Can it use virtual storage?

Performance

1. What is the maximum load this application can handle?
   
2. Can I add more servers if load increases?
   
3. What network bandwidth is required?
   
4. What configuration for user machine is good?
   
5. What can we do to reduce network traffic?
   
6. What can we do to make sure client runs on a leaner machine?
   
7. The load on my server is high, can I partition the data for each business unit and have multiple servers?
   
8. I migrated from one server to another, how can I make sure I do not need to update all users?
   
9. I have some old data I won't be regularly using; can I archive that data and remove from main database?

Security

1. Do we need additional front end machine to secure data at backend?
   
2. What security policies do I need to change?
   
3. How do I define user access polices for every department and make sure they are not able to sneak into each other's data without permission?
   
4. I had a breach, can I analyze the impact from audit logs?
   
5. Oops, a user accidentally deleted a data, how soon can the user or admin recover from the situation?

I will be editing this post as I come up with more questions. In the meantime, if you believe I have missed something obvious, please let me know.

13. Wow! I need it: Blending pre-requisites and exciters

• A house without a bathroom is useless. (prerequisite)
• A family needs 3 bedroom house, will not consider 1 bedroom, but 2 or 4 will still do. (the more the better, but more expensive)
• The view from the house is amazing, I want it!(exciter, unique selling point)

Many features are included in product just to excite a customer to initiate a sales process, but are seldom used. Other type of features are absolute must, just to enter the market, and will be used by almost every user.

However, developing and maintaining exciters is expensive. For example, a builder may buy a expensive land to ensure good view from every house, but may lower down the quality of building material to sell it at a market prevailing price. Almost everyone wants to have good landscaping in their neighbourhood, but is seldom willing to pay for it.

This is where segmenting the market becomes important! For sale to high volume, price-conscious market, usability will be more important than view, but for low volume, quality-conscious market, an amazing view will override pricing concerns, and resource allocation for designing and implementing exciters will no longer be an evil expense, but prudent investment.

To capture a larger market segment, most desirable and middle path is to design a must-have feature is such a way that it becomes a exciter for the high-volume, price conscious market, and advances a product's competitive edge.

Exciters that do not satisfy prerequisite or performance needs should be kept to a minimum, but in any case, exciters should be allocated top priority because they are by definition what satisfies the customer and/or market need.

Bottom Line:

1. Innovation: Finding solutions to prerequisite/basic needs so that they become exciters for the market, i.e. sufficiently implemented and high customer satisfaction.
2. Amount of implementation effort must be controlled by limiting the number of exciters that do not satisfy prerequisite need, and not the quality.
   

Looking ahead

There may be possible scenarios, where initial lower quality/implementation detail is acceptable, and can be progressively improved (for example, fuel efficiency of car). Of Course, the better the implementation, the more customer satisfaction there will be, but at the cost of higher investment.

On an average, for every 10% increase in user stories of enterprise level software, system testing time increases by 100%, and deployment times increase by 30%.

lastly, it might be prudent to keep "will not implement" user stories in traceability map, to avoid duplicate user stories in future.

Inspired from here and here