Node.js video tutorials

Tweet

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

Tweet

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.

Product Management Approach to New Product development vs. Existing Product

Tweet

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

Tweet

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

Entrepreneur as a job title

Tweet

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.

Audible.com

Tweet

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.

Friction

Tweet

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.