Sunday, November 25, 2012

Entrepreneur as a job title


While listening to Eric Ries talk about entrepreneur as a job title within large organizations, I could not help but reminisce about my days at Verizon. Verizon group CIO Shaygan was way ahead of his time as he implemented most of the principles suggested by Eric in his book  - The lean startup. He incentivised the culture of entrepreneurship by making each Director of Engineering responsible for P&L (even if it was just paper money and no real transfer of money took place).

Each Director was allowed to grow his organization as big as he wants to, as long as he can pay for it. If the P&L group could not raise enough money to pay for all the employees it was forced to let go off the resources. Obviously this encouraged group leaders to hire consultants so that scaling up and down can happen without impacting  full-time employees.

Overtime this culture of innovation and competitive spirit gave its way to politics.

Saturday, November 24, 2012

Audible.com

I signed up for audible.com yesterday just to try it out. I also wanted to review the
The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses book as I had no patience to read it the second time. I was pleasantly surprised by how effective audible.com is. Maybe my experience was so positive as I had already read the book. 

The only biggest issue with the audible books is you cannot purchase them within the iPhone apps. I am sure this has to do with Apple insisting that publishers pay 30% cut. I had to buy the book using a website and then download it to iPhone, which takes an effort. Remember my earlier post about reducing friction in user experience.

After wasting time politicking in my new role as a GM at a different kind of company, I am back to writing my book. I am hoping to start publishing some material from the book as blog articles. This will help me get some valuable feedback as well as generate buzz for the book.

Friday, November 23, 2012

Friction


Today I was talking to my friend about a product idea that requires users to take a very simple action to derive value from it. She thought that the product might have an issue with stickiness if it requires users to take an explicit action on regular basis. The reason that Mint works so well is because user is not required to take any action or change his normal routine in any manner. It pulls the necessary data from the bank servers.

The discussion reminded me of something I read in an innovation strategy book about continuous vs. discontinuous innovation. Even a small friction in value delivery can reduce the adoption and stickiness of the product. Users are less likely to adopt to discontinuous innovation, unless the value they derive from the effort to learn or perform an extra action is higher than the effort.



Wednesday, July 4, 2012

Data Driven Product Management

After a long time, I was finally able to find some time for my book (data driven product management). I now have 108 pages of content, ready to be published. I think I am 70% there. Now time to figure out, how to publish on Amazon.

Sunday, June 17, 2012

Graph Database - Neo4j

I have been studying graph databases for last few days for my new company, and Neo4j guys have done a pretty amazing job. If you are not very familiar with graph databases, think of them as a database to represent relationships between objects.

Since the real world relationships are very complex to represent in a regular relational databases, NOSQL databases come to the rescue.

Use case:

  • User 1 is a friend of User 2
  • User 1 is a man
  • User 1 lives in San Francisco
  • User 1 likes Netflix
  • User 1 watched movie seven
  • Users 1 traveled to Paris
The set of properties associated with user 1 like, he is a man and lives in San francisco and the relationships to other objects like is a friend of user 2 and likes object Netflix are very complex to represent in regular relational databases like MySQL. 

NOSQL databases are of 4 kinds, based on the use case. 

1. Key value
2. Column databases
3. document databases
4. graph databases

The above use case is best represented in a graph database. You can get more details by watching http://www.youtube.com/watch?NR=1&feature=endscreen&v=BFTLOABf5oY youtube video.

I will continue writing more as I explore it further.


Sunday, April 22, 2012

Product Definition –startup vs. large company


Startups follow the start-fire-aim approach to product definition as against the traditional start-aim-fire. Basically startups do not have the luxury of time and resources to conduct focus group, gather requirements by interviewing users and then build a product based on the sum of needs. Obviously, they have some idea about the market needs and problems they are solving, but they have not yet validated those assumptions with customers, apart from few visionaries. There is of course the risk of ending up building a product which only appeals to visionaries.

Startups first build a product (start-fire) and then look for customers (aim) who are in need for solutions that this product attempts to solve. Well, what they are building is a minimal viable product (MVP) and hence they are very nimble both in terms of product strategy and technical implementation. They can quickly iterate over the market feedback and adapt. I will talk more about MVP later, but for now, it is sufficient to understand that MVP should include only minimal set of features needed to demonstrate the product solution to few customers (few being the operative word here).

Different dynamics are at play in large firms, as they are either adding new features to existing products where the customers and needs are well understood, or they are working on developing new products for existing market and hence they have good understanding of their customers. They could be looking to expand the existing products in new markets and hence they just need to add few features to meet the needs of other market segments. In either case, they have the luxury of time/resources and opportunity to follow the voice of customer (start-aim-fire).


Recommended books for Product Management


I have been in various roles during my career (software industry), but product management was by far the toughest. Unlike various roles, where practice can increase skills, product management requires true blend of art and science.

These books will not only help you increase your knowledge, but also provide you various frameworks and mental tools, to help improve your product management skills.

Interaction design:


Marketing:


Product Management:


 Entrepreneurship & Customer Development:


Strategy and Innovation:


Pricing:


Metrics and Testing:


These books should at least get you started in the exiting field of product management. As discussed earlier, product management is blend of art and science, so no amount of reading can substitute for your inherent product passion and hard work. Even though fluid intelligence plays a role and is often seen as the common factor among successful product managers, I believe that these skills can be developed over time. These books are part of long series of articles I plan to write about product management. This is an effort both to guide prospective product managers as well as learn through interactions and critical thinking which comes through writing.