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