Sunday, December 30, 2012

Node.js video tutorials

I wanted to create a repository of node.js related videos and tag them for easy learning. I will continue updating them as I find more material.

THE CALLBACK PATTERN by Pedro Teixeira

                         

THE EVENT EMITTER PATTERN  by Pedro Teixeira

                     

Product vs. Engineering Roles

I have spent over 10 years in engineering roles (software engineer, engineering manager and architect) and the last 3 years in product roles (product manager, product marketing manager, general manager). As a product manager (at any level) you are defining the WHAT of the product. As an engineer you figure out the HOW of the product. I will dig deeper into each of these roles below and will also try answering questions like “is a product manager role needed in startups?”, “should engineering report to product or product report to engineering?”

As a product manager, depending on whether it is a startup or a large company and depending on the stage of the product life cycle, you will be working on one of the following phases of the product.:

Opportunity Discovery --> Opportunity Assessment –> Opportunity Validation –> Product Discovery –> Solution Validation –> Metrics (KPI) definition –> Execution –> Go-to-market strategy –> Launch –> Post-launch Assessment.

As a product manager you are responsible for product definition which fundamentally means defining the form and function of the product. You are defining what is going to be built, but not how.

In the execution phase, while engineering is developing features for the current iteration, you will focus on defining features for the next, apart from helping clarify the feature description for the current iteration.

Product definition:

Function

Defining a product involves describing which features need to be built during the next development cycle in detail. If you are using SCRUM methodology for product development, you end up writing epics and user stories describing the product features in detail, maintaining a prioritized backlog of product features, so that engineers can pull from the top of the stack until there is no more bandwidth in the current engineering cycle. There are multiple meetings that a product manager can setup as part of the scrum process to communicate the features. During the product planning meeting, the product manager describes the product features in detail and collaborates on prioritizing them in the product backlog. During sprint backlog, the team decides what they can commitment for the next development cycle and the product manager answers any questions related to user stories. Dependencies between user stories are resolved at this stage as well.

 

Form

As a product manager, you are also responsible for defining the wireframes and visual design of the feature (not applicable if the feature does not have any end user facing component). Obviously you are not going to design them yourself. You will work with an interaction designer in the product discovery phase to finalize the wireframes required for the feature before scheduling it in the engineering development cycle. You will also work with the visual designer to add the look and feel (emotions) to the wireframe, but this can technically be done in parallel with the engineering effort. More on this in later blogs.

As an engineer (or engineering manager or architect) you are mostly involved in figuring out how. You are also responsible for (unless you have a dedicated program manager) to commit to the feature as part of the sprint planning meeting, come up with an estimation and deliver the feature on time with an acceptable quality. You are also responsible to work with product manager to get a sign off and deploy the feature to the production (unless you have a dedicated service engineer).

Now lets get back to the original topic of this article. Do I want to be in an engineering group or a product group?  I think this a very personal decision and different people have different opinions. Product definition is inherently a creative job which appeals to many. Engineering gives you the satisfaction of actually being able to implement your ideas and vision. I have struggled with this question for a long time. When I was running engineering groups, I longed for product roles. As a product manager, I feel helpless when I cannot just roll up my sleeves, sit with engineers and develop it the way I think it should be developed. Maybe most of these frustrations are due to dealing with few inefficient engineering managers, but never the less you run into them frequently.

I will side track for a moment to discuss what I mean by product development. A product development group has the following key roles.

1. Product manager to define the product being built.

2. Engineering (including engineering management) to build the product.

3. Architect to define the technical architecture.

4. Designers (both interaction and visual designers) to create wireframes and visual assets.

Each of these roles is self-explanatory and they are all critical for building a successful product.

Back to the original discussion now; after a long and considerable thought, I would rather run the product development group or have the title of Director of Product development than have the role of Director of engineering. That way I can be responsible for both product definition and product execution. Anyone who has engineering background and has successfully transitioned into a product management role, will be a perfect match for this position. This will eliminate the debate whether product should report to engineering or engineering to product. It will bring both the groups into a single umbrella and get the work done faster. The team can focus on delivering a successful product, which is valuable, feasible and usable.

I will talk more about this in the next article. The article is long enough already.

Saturday, December 29, 2012

Product Management Approach to New Product development vs. Existing Product

I wanted to compare and contrast the product management approach to developing a new product vs. adding features to an existing product.  I have been thinking about it for a long time and after skimming through numerous product management books and discussing with fellow product managers, I believe the below approach makes a lot of sense.

New Product:

Opportunity Discovery --> Opportunity Assessment –> Opportunity Validation –> Product Discovery –> Solution Validation –> Metrics (KPI) definition –> Execution –> Go-to-market strategy –> launch –> post-launch assessment.

Opportunity discovery = ideation, but often the opportunity is presented to you either by either the founder in a startup environment or by a senior executives in a large company. It is difficult to cover each of these definitions in this article, but they are self explanatory. I will try to add more details in future.

Each of these phases are important and based on where you are in the product life-cycle (introduction, growth, maturity, decline), you might encounter one or more of them.

Existing Product

Compare this to the approach which generally works for adding features to an existing product where you analyze the usage metrics, come up with feature definition which could move the needle in the right direction, develop, deploy and measure. This cycle of build, measure, learn is very well documented by Eric Ries in The Lean Startup book.

 

I will try not to get into too much details, but it is suffice to say that the approach to product management for a new product is very different. While working on an existing product, the customers are known, their needs have been established, the solution has been validated and we now have a known product/known customer scenario. In the new product scenario, both the market and the product is unknown. You are not sure, if there is an opportunity. Even if there is one, is the need  strong enough that they are willing to pay for a solution. You have no idea about the solution and if it  has significant value proposition. You probably do not know who your customers are in the first place. Eric covers it very well:

 

 

Market Product Methodology

Known

Known

Waterfall

Known

Unknown

Agile

Unknown

Unknown

Lean

 

In the lean start up approach you have to focus on the customer development in parallel to product development. Read Steven Blank’s The Four Steps to the Epiphany for more details

Windows Live Writer

Windows

I have been looking for a good desktop client to manage blogs for sometime now. Based on some research, I found Live Writer from Microsoft. So far it is working out pretty well. http://www.microsoft.com/en-us/download/confirmation.aspx?id=8621

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.

Saturday, April 21, 2012

IntelliVocab hits half a million users

In our efforts  to pivot Faqden Labs, we completely neglected  IntelliVocab for over last 6 months. We were surprised to see few weeks back, that we have silently hit 500,000 users and still going strong. It is still rated as the top 10 SAT and GRE app on app store. As I wrote multiple times in the past, running a company with multiple co-founders with diverse background is probably the single biggest challenge you will face as an entrepreneur. 

We had been struggling with split focus between education apps, enterprise apps and services since our inception. After a long and prolonged discussions, we decided to shut down our services group and focus exclusively on products. Within product we split the company into 2 separate division, one focusing on enterprise apps (www.xibird.com) and other focusing on the original vision of the company (education apps - www.faqden.com).

With renewed focus on turning around our education related product line, I am hoping, we can move the company back to its former glory. I will continue writing about my experience with the turn around efforts and challenges so that other entrepreneurs can benefit from it. Obviously this is good news for our IntelliVocab users as they will start seeing updates every couple of weeks compared to 0 updates in last 6 months.