Archive for the ‘Product Development’ Category

« Older Entries

Software Services Organizations calling Mother Earth – “Houston, We have a Problem!”

October 24, 2009

It is now more than 4 years that I have been part of Software Services Industry (focused on providing IT/Software outsourcing solutions) after all my previous association with mostly product organizations – big and small. It has been an interesting experience for me – especially considering that my job (at GlobalLogic – focused on Outsourced Product Development business) requires me to play a role across Strategy, Business Development, Sales, and Delivery all throughout the years. Compared to many others in the Software Services Business – some might consider me as a relatively late entrant. However, these 4 years itself has given me enough perspective to think sincerely as to where this industry is going, what is working for them and what ails them too.

Now with lots of personal experience, after talking with many who have been part-of or have been associated in various capacities with Software Services companies, and scanning the internet for software/economic trends – I think I have started reaching some core prognosis and hypothesis for the state of software services industry. As one of the crew member in this software services industry spaceship I am now ready to acknowledge -  “Houston, We have a Problem!“.

Before I proceed further, please note that my prognosis is not about a dooms-day scenario but about certain ills which if not addressed soon can possibly adversely affect the long term growth of software services industry.

Here are some of the challenges which I am seeing that software services organizations are facing from a global business perspective -

  • Cost arbitrage is no longer the differentiator – Regardless of what many say – ability to help customers bring their costs/expenses down and at the same time scale too is of big value and will continue to remain so. So services organization providing any offering (while maintaining other attributes like quality, reliability, etc. constant) which successfully demonstrates this will always be attractive. However,  there is always a lower limit beyond which the costs cannot be reduced. Entry points for other competitors to claim that they can provide better cost-arbitrage value is relatively very easy. So for organizations for whom cost arbitrage was the only value proposition they could offer for years – world is now catching up fast with them.
  • ‘Cost Arbitrage‘ and ‘Value‘ are like oil in water. They do not mix! – Having realized the above challenge – many services organizations have now seriously putting in efforts to provide their customers value-added offerings beyond just cost-based offerings. Value added offerings are typically based on specialized skills, domains, business partnerships, etc. However, while there might be few cases of successes in this way, my personal opinion is that majority will have a challenge selling ‘value’ to their customers along with cost arbitrage solutions. Providing cost arbitrage and also providing value are inherently conflicting offerings. (Anyone who has read my previous blog post – “Psychology of Consumers During Consumption of Products or Services” and the associated article would probably agree with my view point).
  • Need to shed away inward focus – Considering the nature of the business (especially when the focus is more on Point # 1 which I listed above) – substantial portion of services organizations efforts and energy is increasingly focused internally to manage people, salaries, delivery, costs, lunches, operations, personal aspirations, etc. assuming that this is key to their bread and butter. Very crudely, I would compare this to the day-in-the-life of a shepherd managing his herd of sheep. Ratio of number of people focusing on internal operations to number of people interacting with the external market/business has to reverse in Services Organizations.
  • We cannot keep just consuming, we need to produce too! – Substantial number of Software Services organizations (including where I am employed) have been in business for long period of time and majority of them today can boast of servicing huge number of businesses / products / domains / technologies under one roof. InnovationOver the years majority of the services companies have done this by ‘consuming‘ knowledge / experiences / technologies / best practices produced by someone ‘not‘ under their roof. I am not saying this is wrong or bad. However, I am also assuming that with the years of experience under their belt now (again across domains, technologies, best practices, etc.) – software services organizations should be in much better situation to contribute back new discoveries/inventions/practices, etc. to the industry. We need to ‘produce‘ too! So I will confess here that in the day-to-day tactical efforts to manage points listed above, majority of services organizations are not able to properly concentrate on this count.
  • Surely, we will get recognized by the company we keep; but we will finally get valued by the work we do! – Take a random survey of the Software Services Organization portfolio and look at how many of them claim that they work for a ‘Microsoft’ or a ‘Oracle’ or a ‘Cisco’. More than half of the thousands of Software Services Organizations would (honestly) claim that they do. Without any doubt that is the first big achievement. Now find out how many of these organizations do the Microsofts or the Oracles of the world acknowledge in their products that it was built with these organization’s help. Getting recognized or people knowing about us is one thing, but people acknowledging us as a thought leader is completely different matter. IMHO, majority of the Services Organizations still have to cross that bridge.
  • and finally – focus on building the Taj Mahal, not the number of people billed to build the Taj Mahal – Perhaps slightly related to above point but a different perspective! Almost all of the customers of the Software Services organizations are focused on building something which they strongly believe would be the next Taj Mahal. Special, different, beautiful, strong, ever-lasting, etc.! The focus of organizations like mine should be on that. The number of people or hours billed in a billing cycle – though important – is a temporary thing and will eventually get replaced from the records with the change in the financial cycle, but if we can help an organization to be the next Cisco – the returns are going to be far better.

My intention in this blog post is not to crucify anyone or any particular organization, but to point out few things to correct the course. And this case, I am pointing these things out to the organizations which I am happily part of. Like in any retrospection along with an introspection discussion, I am possibly expecting a polarizing reaction from readers to my blog post. However, the key for me here is to start the debate and hear your view points. So let the comments/feedback/fires flow in.

Tags:, , , , ,
Posted in Product Development | 2 Comments »

Why Product Development today needs a Product Engineering Platform?

September 25, 2009

[Note: I seem to be landing up on many of my articles which I had written in my pre-blogging days. Few weeks back I had posted another one titled "QA Tester vs. QA Engineer vs. QA Architect". Once again, rather than having it cold-stored on my file system, I am posting it here with the hope that it might be useful to the wider community.

As a background on this article - this was written when me and my team were in process of conceptualizing the need for an integrated engineering platform in GlobalLogic because of the increasingly different product development landscape today. The motivations and need listed in this article finally resulted in the evolution of what today is referred to as GlobalLogic Velocity. It also won the "InfoWorld Top 100 Innovation Award" for the year 2007]

Main Motivation – Art of Product Engineering Today

There is no doubt today that teams are becoming increasingly distributed. Also the art of building products is rapidly changing now, more than ever in the new world of Web 2.0 or SOA. Product Development is now less upfront and more emergent. Requirements are driven more driven by Black-board, IM, or Wire Frames. Product Development today needs to be more collaborative and collective. The testing process for products is more continuous rather than at the end of the cycle with the practice of Test Driven Development. End users have also started playing a key role in this testing process. Table below provides a quick comparison of how the art of building software products has changed. As tough as it is to practice this in a uni-location team, complexity is much higher in a distributed team.

Then Now
Primary Collaboration Mechanism Mails, face-to-face, one way media (documents, etc.) Web, Sticky Notes, Wiki, IM, Black Board, Wire Frames
Source of Innovation Industry Technology Leaders Users, Customers
Release Cycle Months, Years Weeks, On Demand
Feedback Mechanism Market Research, Surveys, User Group Study, Customer Support Online, Continuous, Community Contribution
Customer Engagement Style Controlled, well-defined Spontaneous, Chaotic
Development Process Upfront design Less upfront, more emergent
Product Architecture Closed, Grounds Up Open, Built to extend, Reuse
Product Development Culture Centralized, Departmentalized, Linear Approach, Individual Heroics Distributed, Highly Collaborative and Collective, Partnership-based
Product Testing Internal, Dedicated Test Teams, Ownership-based, End of Life Cycle Continuous, Test Driven Development, Users as testers
Development Tools Heavy enterprise oriented, expensive, complex. Lightweight, Simple, Free, fast.
Product Engineering Art – Then and Now

One of the thing which becomes clear from the above comparison is that product development is just not about core product knowledge, but also about about understanding the design and the product engineering processes. The different phases of a lifecycle engineering are becoming increasingly more collaborative and knowledge intensive. Thus a product representation must convey additional information/knowledge that answers not only “what” question about a product engineering but also “how” and “with what” questions.

Product and Stakeholders Dynamics in an Organization

Another factor which governs the product development is the way internal department structures are modeled within the organization. Typically there is a Product Management group which interacts with the end customers and prioritizes the business requirements based on the market needs. Program Management has the responsibility of prioritizing these requirements internally along with the roles and responsibilities. Program Management also needs to bridge the gap which typically exists between the business side and the technical side. Product Development Management then takes the requirements and converts that into a working software. Quite occasionally, organizations also have Product Delivery Group which is finally responsible for delivering the software to its users. Figure below represents such dynamics within a product organization
Product & Stakeholder Dynamics in an Organization

Product & Stakeholder Dynamics in an Organization

While the distribution of product development work across departments helps in work categorization, it is also important for Management to have one view of the state of product development. This becomes much more complex when the entire product development is spread across geographies or time zones. Hence there is a need for an efficient integrated platform which aids the complete life cycle of the product.

Any Product Engineering Platform should be an integrated set of applications, systems, repositories and tools used by Software Product Engineering teams which would facilitate -

  • Integration of technology/applications
  • Integration of the business/engineering processes
  • Integration of information and knowledge
  • Integration of people and organizations units
Any Product Engineering Platform (including ours) should be able to facilitate the above characteristics.

[Note - Partial credits to the table titled "Product Engineering Art - Then and Now" mentioned above goes to an article which I had read on the internet. Unfortunately I am not able to locate or find the reference to it now and the old link has now disappeared too. If anyone has any reference to the same, would be great if you could point it out.]

Tags:, , , , ,
Posted in Product Development | Leave a Comment »

QA Tester vs. QA Engineer vs. QA Architect

September 11, 2009

[This article was collectively written by few of my colleagues and myself few years back when we were in process of structuring the QA Organization framework. I landed upon it today while I was going through some of my old notes. A lot of collective experience and brainstorming had gone into it. Publishing it here with the hope that it might be useful to a wider community.]

Background:

Our organization’s target customers are typically Independent Software Vendors (ISV) and Application Service Providers (ASP). For such typical partners, Software Product Engineering is an exercise in managing complexity. The complexity exists within the software design itself, within the software organization of the company, and within the industry as a whole. It can span multiple technologies and often involves multiple sub-disciplines. Software specifications tend to be fluid, and change rapidly and often, usually while the SDLC is still going on. Software teams also tend to be fluid, likewise often changing in the middle of the design process. Hence it is important that the team has to have the ability of making decisions under constraints of limited time, resources, and knowledge. This is where the notion of Engineering holds its value.

Engineering is more about how you do the process than it is about what the final product looks like. Programming and the build/test cycle are central to the process of engineering software. We need to manage them as such. The economics of the build/test cycle, plus the fact that a software system can represent practically anything, makes it very unlikely that there are any general purpose methods for validating a software design.

Considering the above the Engineering aspects and the non-engineering aspects of Software Development needs to be identified. Also, it needs to be recognized that there are specialists who are well-versed in doing either of the tasks. These specialists typically originate on the basis of their educational path or as in many cases – the aptitude. At the same time it is important that the expectations of the capability of the individuals needs to be well-understood by all the stakeholders. Any mis-match in terms of capabilities and expectations, typically tends to adversely affect on the final outcome of the SDLC delivery.

While this applies to all the domains of SDLC, this exercise is being done for professionals who are involved in the Quality Assurance (domain). The goal is to categorize these professionals based on their inherent capabilities (and hence the expectations set on them)

Assumptions

  • The table below characterizes three different roles. These roles are similar from the functional perspective (i.e. Quality Assurance), however are different from capabilities and expectations perspective.
  • While the table below does not suggest a career roadmap, it can help individuals in terms of career aspirations.

Comparison of Roles:

QA Tester vs. QA Engineer vs. QA Architect

QA Tester QA Engineer QA Architect
Function – Strong in test execution. Function – Test planning, Test Design and execution. Function – Define approach to test entire systems
Write and execute test cases – may not be coverage driven. Requirements driven testing. Prepare test plans, develop test cases and execute tests with a focus on coverage. Design, plan, execute, monitor, improve testing process for a testing engagement.
Determines Quality. Good to answer – did you find any bugs? Engineers Quality. Good to answer – what is the quality of the product? Provides answers to -

  • What are the quality attributes and goals of the product?
  • What should be the test strategy, methodology and test tools so as to ensure product quality?
Linear thinkers, low capability of analysis and re-usability of efforts/resources. Logical thinkers. Ability to resolve issues using abstraction. Capability in analysis/predictions/improvements. Analytical and creative. Systems thinking and quantitative/statistical thinking capabilities.
Requires a defined environment. Typically are weak in finding solutions in ambiguous/constrained environments. Can reconcile conflicting constraints. Able to define the environment.
Low process oriented capability. Process and metrics/measurement driven. Defines standards, guidelines, methodologies, metrics.
May not be cost sensitive (time, effort, monetary, etc.) Cost sensitive Cost sensitive
Good for UI Testing

  • Regression testing
  • Portability testing
 Good for System/functionality testing

  • Performance testing /Automation
  • Independent validations
  • Domain testing
  • Programming skills orientation
 Good for defining, planning and managing for test engagements.
  • Ability to understand the goals of an organization and suggest a test architecture.
  • Able to suggest alternative approaches and benefits of the same.
  • Ability to suggest improvements to process and technology areas for a test system.
  • Ability to define the framework for testing.
  • Ability to analyze risks and provide mitigation plans.
  • Ability to analyze test requirements and provide a solution in terms of test approach and design, suggested tools etc.
  • ability to design the entire test life cycle processes.
  • Capability to lead and co-ordinate a team of analysts for testing engagements.
  • Software development skills.
  • In touch with new methodologies and tools for software testing.
  • Ability to design, plan and execute and monitor a testing process.
Typical involvement is in later stage of SDLC Best to have them involved in complete SDLC Cycle. Best to have them involved in complete SDLC Cycle.

Tags:, , , ,
Posted in Product Development | 8 Comments »

Chief Product Officer – Does your Organization have one?

May 26, 2009

Over the last year, while working with many of the consumer oriented businesses – I came across various scenarios where I had to compare the role of Chief Product Officer (CPO)  in comparison with the role of Chief Technology Officer (CTO). While industries are well familiar with a typical CTO role and what he/she is supposed to do, the role (and of course the need) of CPO still seems to be confusing to many. Do organization need both? Is one the replacement for other? And so on.

I tried making a Google search for the job description of CPO; however could not find one. However, I did come across several search results associated with the announcements of CPO in several organization. This makes me believe that this role is still not part of main stream. Also, an interesting observation you would see when you make this search – seems like most of the industries in end-consumer interfacing/used products are the ones who are making investment in this particular role.

So what is a CPO? PTC in one of their press release has made an attempt to describe this role. One of the analogy they have used is with the role of CFO – the way CFO is to Finance in the organization, CPO is to the product. Traditionally organizations have had fragmented responsibilities in terms of product ownership within the organizations. Product Management/Product Marketing looks at the product more from the strategy and product vision perspective; CTO looks at the same product more from design and development perspective; while VP Engineering is more responsible from an execution or product development angle. Almost 80-85% of the organizations with whom I have interfaced have typically been organized in this fashion. However, I have started seeing that many organizations have started having second thoughts on the dispersion of these responsibilities. Hence the role of CPO – someone who looks at product from an end-to-end perspective; someone who can act as a visionary and at the same time be realistic in terms of execution also; seems to be getting into prominence.

IMO, there are also some other factors which is possibly forcing organizations to think from a CPO perspective.

  • For many products, especially the ones in end-Consumer oriented, technology has now started becoming a second fiddle. By technology becoming second fiddle is not to say that technology is not important. I mean that in such applications it is not the technology which drives the user pattern, but it is the user behavior which tends to drive the technology and engineering. In such applications, the head of the product needs to be more nearer to the customer rather than just getting driven by technology & engineering.
  • More and more products are also becoming hybrid in nature i.e. products are getting built-up because of partnerships between multiple relationships. In products such as these, the need is to have someone with his/her responsibility spanning across vision and strategy, design and development, product marketing and management, and partnership management.
  • On the similar lines as above point, as Engineering and Product Development is becoming more and more commodit’ized – many ISVs today are becoming more and more dependent on their partners in helping them out on this rather than growing an in-house expertise on technology front. So from an in-house expertise perspective, organizations have started looking the role of CPO with more interest.

I also think that by investing in a role of CPO, organizations have started becoming cognizant of the fact that they need to start becoming more inclusive in their product evolution and development side – both internally and externally.

I would love to hear your thoughts – especially if you are/have played the role of CPO in your life. If you also have interacted any of the CPO out there, would love to hear your thoughts too.

Tags:, , ,
Posted in Marketing & Strategy, Product Development | 1 Comment »

Assembly Line Software Product Development

May 24, 2009

Compared to many of its engineering counter-parts like Manufacturing or Civil/Construction Engineering, Software Engineering, IMHO, probably still has not come to the level where one can see the maturity of standardization across. There are lots of arguments for this and many of them quite valid. Many consider that in Manufacturing (and similar engineering fields), it is all about creating the same thing again and again. Whereas Software is about creating something unique every time. Also, purists do differentiate between Development and Production. Few authors have said that Development is like creating a recipe, whereas Production is like following that recipe. So the variability in both Development and Production should be expected.

I am not going to disagree much with many of the arguments listed above. With more than 20 products I have been actively involved in my career, I know that each one of them had its unique DNA. Each had a big element of variability and trial-and-error model of software development. So I will agree that the expectation of standardization across them would have been far-fetched. However, my talking point in this post is that while at an Application or Product level – things can be difficult to standardize, however at a software delivery level things can certainly be standardized. For me in this post, software delivery signifies what Assembly Line signifies in a Manufacturing scenario – an arrangement of workers, fixtures, processes, and equipment in which the product being assembled passes consecutively from operation to operation until completed.

As part of Version 1.0 program, my team and me took many of the concepts of the manufacturing assembly line at an abstract level and configured them to apply that in our Software Delivery to a significant success. While we were building multiple products each with a complete different and distinct DNAs – we were also keen in making sure that these products go through certain arrangements which were common across all the products. (The possibility of developing multiple products in a Services organization certainly gave us this flexibility to experiment with such concepts; however I think many of these concepts can even be applied in product organizations where multiple product lines/releases do take place)

Here are some of the concepts which we believe resemble the practices of assembly-line software engineering -

  • Standardized Process for a Release – We felt that regardless of the type of product under development – we could standardize the process of how we go ahead in terms of making a product release across all the products. Here are some of the concepts which tried religiously following all across -
    • Use of Iterative way of Product Development Methodology. We even went to the extent of standardizing each of the iteration length to one month across all products.
    • Atleast one dedicated Design iteration would always prelude the Engineering Iterations.
    • Each iteration had fixed set of activities associated with design, development, and tests
    • Typical Releases across all the products were equivalent to 3-4 iterations.
  • Standardized Milestones across the Release – Every product went through similar milestones – Requirements Prioritization and Iteration Plan Development; Retrospection; Deployments, etc.
  • Standardized Product Engineering Fixtures and Tools – While the core product development platform varied from product to product, we made sure that the core underlying engineering platform which facilitated product engineering processes like Requirements Management, Project Management, Continuous Integration, etc.  were as similar as it could get.
  • Standardized Team Structures and Roles – While team size varied based the product complexity – we made sure that the team was organized into two groups – the functional group and the engineering group. Each group had some roles (such as Product Manager, Architects, Program Manager, Engineering Leads, etc.) which were common across all the products. The roles were well-defined so that each individual knew what was expected from them at each stage of the product life cycle.
  • Standardized Measurements and Continuous Improvement Mechanisms -  Each of the products across their life cycle were getting measured by common metrics on the dimensions of quality, schedule, and customer delight. We also made sure that the process across all the products had Continuous Improvement loops built in through methods like Retrospection, etc.

I think Software Engineering with the knowledge of millions of software products delivered to the market across decades can be standardized to significant extent similar to its other counter parts. Once again, I am not saying that recipes can be standardized. However, my argument here is that the process of creating that recipe and delivering that to its end users can certainly be standardized to a great extent.

Thoughts and comments are most welcome.

Tags:, ,
Posted in Product Development | Leave a Comment »

Honey, I destroyed my product by adding too many features!

November 30, 2008

The temptation associated with squeezing in as many features before it gets into the user’s hands is typically very overwhelming for any product entrepreneur. This is especially true when a new product is being launched in the market for the very first time. A typical assumption behind this is that the probability of users accepting the product is directly proportional to the number of the features which the users find in it. The notion that the products just have one chance to get to the eyes of the potential users or buyers also fuels the urgency behind squeezing in the features. This a classic dilemma for products today.

Per the standard practices prevalent in product engineering today, the standard practice is to classify the features to be developed into different Priority Buckets along a scale. e. g. Priority 1, Priority 2, and so on. This scale may vary amongst various product groups. However, broadly this scale typically gets classified into three kinds of buckets – “Can’t go to market without them!“, “Lets do it if we have time!” and “Forget about it right now but I am so glad you documented it!“. Once the features or the requirements are classified in this manner, as a standard practice it is typically a race against time to see how many of these can be implemented.  If the team is able to implement the most from this list – they are considered to be the most efficient. It is also assumed that the product is better off once most number of the features from the list gets implemented.

However, in my opinion and experience – there should also be another way to look at the feature queue. The requirements prioritization should also take into consideration to understand if there is a threshold beyond which any addition of features would start affecting the product in an adverse manner. This threshold could be from the perspective of count of features or the spread of features from functionality perspective. Features and functionality in the product are meant for empowering the end users to fulfill their needs with the maximum amount of ease. Beyond a point, the additional features can make this task more complex and may actually result in turning off the user from using it.

Every product needs to have a core value proposition and a defined user base which it targets to. In my opinion and experience, the tendency to squeeze in as many features as possible in the product is typically associated with both. It can mean an incoherent understanding of the needs of the potential user base or probably a sign of weakness in the core value proposition associated with the product.

Any features which needs to go into a product should be focused around the few key value proposition which the product has to offer and how to do that in the best possible way. Increasing the breadth of features may enable the product entrepreneur to fill in a check list associated with a long list of features and claim “we have that too!”. However if this comes at the cost of diluting the key messaging associated with the product – this may just might mean the doom for the product.

Any thoughts or comments are welcome!

Add to Technorati Favorites

Tags:, ,
Posted in Agile Methodology, Marketing & Strategy, Product Development, Startups | Leave a Comment »

Applying Concepts of “Packs” to Software Development Teams

October 4, 2008

In one of my post couple of months back, I had written about my fascination about the African Wild Dogs. In the same post, I had written that some of their amazing habits as a pack can be translated into some real practices in our real life especially in Software Project Management. This post is about the same.

On the on-set, let me say that many of you may find my correlation between these dogs and software teams a bit far-fetched or even crazy. Some of you may even feel this post a slightly condescending on my part to compare software teams aka. people and dogs. But please hear me out!

As I had pointed in my post linked above, the whole notion of these animals surviving and succeeding in the extreme wild as a pack is something which got me thinking of what can we learn from them to build effective teams. My experience has been in building software teams so I will limit my conversation in this blog to Software Engineering Teams. However, I am guessing that my thoughts here could apply to building any type of team/s.

Pack animals by nature live in bunches and their survival depends on how they live as a group and interact amongst each other.  Same as these African Wild Dogs, Human Beings are also Pack Animals. In a social sense we are all designed to live as Packs. We need others to interact with and also depend upon. However, IMO, there are many additional things which these animals do much better than us as a pack. Some of these additional things – or let me call it as characteristics – is something I think can be impersonated by us too especially when it comes to building a rock-solid successful Software Development Teams. Here are some of those characteristics -

  • Moving together and hunting together = Certainly Software Teams are not literally hunting anything; however this point does apply to the key point that the team should get on a key new mission collectively rather than individually. A team which is well-gelled together can collectively approach a new mission in a much successful manner.
  • Individuals while they operate in a pack, maintain unique role for themselves, but can play different roles if required = It is important that in a team, each member should have an unique ability individually and have their individual quirks, traits and characteristics that make up their personality. However, the members of the team should also be able to quarterback the other roles if required. Each team member should have the ability to play to other’s strength and complement wherever required for other’s weaknesses.
  • Pack Subordination = This can be slightly tricky if taken literally – because it can imply a hierarchy or weaknesses in the team. I don’t mean this in this manner. By subordination, I mean the team exhibits mutual respect and affection for each other and not fear.
  • Inherent desire to keep harmony in the group = The above point and this is inter-related. This tends to be the sub-conscious behavior of a ‘well-packed‘ team. The team thrives best on companionship.
  • Get driven by Learnings and not just Instincts = As I had mentioned in my previous blog, one of the key characteristics of these African Dogs as compared to other animals was that they typically are not instinctive hunters. It is my opinion that individuals get driven by instincts, but a team needs to get driven by Experience.
  • Cursorial hunting ability  = The team should have a long distance running ability to achieve their goal.
  • Holistic View rather than Individualistic View = The strength and progress personified more by the team rather than individuals.

If it helps in recognizing the value of having pack characteristics in a team – get this! Pack animals have the biggest success rate in their hunts as compared to other animals. We have successfully incorporated imbibed some of these characteristics in our teams (we call them as Velocity Packs) and now has become a key part of our offering in Version 1.0 in GlobalLogic.

Thoughts and comments are most welcome!

Add to Technorati Favorites

Tags:, , , ,
Posted in Product Development | Leave a Comment »

Applying Theory of Triple Constraints to Early Stage Products

September 14, 2008

Two things I need to expand upon before I delve into this post. Describe what I mean by ‘Early Stage Products‘ and then expand on ‘Theory of Triple Constraints‘.

While there might be many perceived perceptions of what an ‘Early Stage Product‘ means – for the discussion in this blog I am implying to a product which is typically at a pre-market validation stage. The product is still being conceived and built.  The hope is that after this stage (within our group we refer to it as Version 1.0), the product would be rolled out to its potential users which in-turn would facilitate the potential revenues. The primary goal of products at this stage is to get a real-world market validation – beyond just surveys, interviews, and reports. The organization which is building this product may be a start-up or even an established organization ready to launch a new product offering. Products in this stage may or may not be financially bootstrapped.

Now regarding “Theory of Triple Constraints“! This is nothing new. For anyone who have gone through Project Management – 101, would recall the picture of triangle with Scope, Time, and Money at its node.

Theory of Triple Constraints

Theory of Triple Constraints

Alistair Cockburn refers to it as “Iron Triangle for Software Development“. What the Theory of Constraints is telling us is that there are three variables of a project which one needs to manage for its successful completion – Scope (what needs to be built), Time (time required to get it built) and Money (money required to build to what is there in the Scope in the given Time). Change in any one of the variable can affect another or both of the other variables.

[Few folks have asked me about Quality as the variable. While I have seen this Triangle being morphed to include Quality too, personally I would like to think that in modern-day products, Quality is part of the Scope. Also, with the rising use of Agile ways of Product Development, a lot of assumptions associated with this Triangle are getting questioned. This is a topic for discussion on another day though.]

Now coming to the main topic of this blog – applicability of Theory of Constraints in the development of Early Stage Product considering the real-world constraints under which it is typically developed.  In all my experience of working with products trying to reach Version 1.0, I have seen the following to be always true.

Theory of Triple Constraints - Early Stage Products

Theory of Triple Constraints - Early Stage Products

  • Time to Market: How soon can one take the product to the market or Time-to-Market is the most important driving aspect for 99.99% of the early stage products today. I have left the 0.01% for products which are hopefully going to solve the cancer or hunger problems of the earth. The theory behind Time-to-Market is that because of the ever-changing needs of the consumers or increasing competition, there is a limited window which is available for a product to be launched. So with this, it is essential that the Time variable cannot be (or should not be) changed for such products – at least to the higher side.
  • Limited Cash: As I had stated in one of my previous blog, almost all product entrepreneurs today operate with a limited inflow of money or a fixed budget. This is also constrained because most of the products in this stage do not have the backing of revenues too. Under such scenarios, it becomes extremely important to lock-in the Cost variable too.

So the only variable which now remains is Scope. For anyone who has gone through an experience of the product development, this is one variable you want to keep as a Variable! And this is especially true in early stage products.  Many a times, the scope which is true in the morning may not be true in the evening. Also, any events which affects both Time and Cost, would need to be potentially adjusted by varying the Scope.

During my discussions, many have asked me as to what happens when some Scope has to be fixed from the “Go-To-Market” perspective. However, IMO, if you agree with me in the above para that scope is a variable, this is probably a mute point. Second, if things come to such a stage that all three variables have to be fixed, one of the first thing to assume would be that the initial planning was not upto the mark.

I would welcome your thoughts and comments.

Add to Technorati Favorites

Tags:, , , , , ,
Posted in Product Development | 1 Comment »

Product Development – From Idea to Reality…

August 24, 2008

It has been some time since I have blogged. As usual, hectic work schedule over the last month took the toll on my blogging habits. Not that I am complaining about the same. The last month went into some wonderful work. On a personal front, it was an enriching experience for me to work in a high profile environment and to look at things from a completely different perspective. It also was a big validation of the GlobalLogic Version 1.0 Offering which we have put together recently and now have taken it to a completely different level. The ability of the entire team to come together to understand, comb through the issues, and deliver was very fulfilling to see.

While I will not go through the details of the project, the key challenge for us as a team was to help a high profile client of ours to go through a series of planning activities to convert an idea to a product and then take the product to form the base of a successful new organization. Envisioning a concept getting converted into a real enterprise product is not a simple task. IMO, almost most of the times how well one executes the tasks associated with product development supersedes the brilliance of the idea itself. Product Development today is an ardent task in daily-changing business scenarios and tough competition. In addition to that one has to hash through the combinatorics of available go-to-market options, product visualization, technologies, competition, risks, and partnerships and come up with a clear strategy. This requires broad and experienced heads to come together and work around evolving the best plan forward. This is where my team comes in. Our work starts with understanding what is driving our client to his/her vision; go through the multiple dimensions of issues; and come up with a prospective plan. There is typically no one single perfect plan to build a product. However, simply putting things in proper context and perspective can be of great value. Almost all our clients vouch for that. The main questions which we help them answer are -

  • What are we trying to build?
  • How will we build it?
  • What is it going to take to build it?

It is not easy to answer these three questions to the highest degree of correctness. One has to put the past experience to work a great deal here. However, the biggest criterion here is how to make the plan Agile and Adaptive. That is the key.

Add to Technorati Favorites

Tags:, , ,
Posted in Marketing & Strategy, Product Development | Leave a Comment »

The Engineering Aspects of Software Estimation.

July 11, 2008

Before I jump into this post, let me describe what I mean by Engineering Activity. An activity where knowledge of relevant science is applied to achieve the required result is an Engineering activity.

I was reading this paper titled “Large Limits to Software Estimates” (PDF link) by J. P. Lewis (published in ACM Software Engineering Notes,Vol 26, No. 4, July 2001). I am not much of a mathematical theorems person, so I skipped the initial few sections and came to the conclusions part. In the conclusion part, the author raises the question – “Should Software Estimation be called as Engineering?“. He argues that if we were to consider Software Estimation to be an engineering process, then litigation/conflicts should be a reasonable or acceptable outcome for incorrect estimations. If not, the author raises the questions associated with ethics in the software community – considering that so many estimates are ill-founded or bloated. The author also points to another article titled – “Are We Developers just liars or fools?” by Robert N. Charette. (If you are not ready to pay to ACM for this, here is a link to a similar article written by the same author.)

Before I jump into writing my thoughts on this one,  I wanted to point out to a quote from Hannah Arendt, a self-claimed German-Jewish political theorist, which I had read sometime back.

Promises are the uniquely human way of ordering the future, trying to make it predictable and reliable to the extent that this is humanly possible.

To come to think about it, software estimation is also about trying to make the future predictable and reliable. However, except probably the psychics, I am not sure how many of us would make a claim on predicting the future to the reliable extent. This brings to my next point.

Anyone who has been in this business, doing software estimation is one of the toughest job. If given a choice, most of us would probably prefer the “will call you when it is done” approach for communicating the estimates.  While I agree with J. P. Lewis that estimation should be based on sound engineering principles; however in reality that is rarely humanly possible in software business.

Most of the estimates today are based on past relative experience and gut feel of the individuals even if the functionality is broken down to the nearest function points. I am not saying this in any negative way. Almost all who have had some good relative experience in this business would realize the fact that software development is a process of gradual refinement. This is especially true in today’s world of internet-enabled mass-consumer products as compared to a decade back. We have to keep in mind that both the consumers and the producers of the software products are in the end human beings. IMO, it is hard to find human beings who know what exactly they want consistently. Because of this the software estimation process is going to remain fuzzy in the initial stages and typically gets better refined with the time. So Robert Charette’s argument that software industry should stop reporting incorrect estimates in order for it to be held up for respect and emulation is slightly naive in my humble opinion.

Software estimation should be treated for it really actually means. Dictionary meaning of estimation is “approximate calculation“. And the dictionary meaning of approximate is “nearly exact; not perfectly accurate or correct“. Estimates like in any other context should be treated as a guideline. All the trouble starts when it starts getting treated as a quote or as an actual quantitative number. I am personally of the opinion that estimates can never be challenged; only thing we can do is to help improve it.

So if I were to plagiarize Hannah Arendt’s quote mentioned above and apply it to software estimates, this is how it would read -

Promises Software Estimates are the uniquely human way of ordering the future, trying to make it predictable and reliable to the extent that this is humanly possible.

I would love to hear your thoughts or comments.

Add to Technorati Favorites

Tags:, , , , ,
Posted in Product Development | 2 Comments »

Developer Productivity vs. Runtime Performance of Programming Languages

June 16, 2008

Although we have been playing around with it for more than year and half now, over the last few quarters my company (GlobalLogic) has invested heavily in and adapted the new generation development platforms like Ruby-on-Rails (RoR), Adobe AIR, etc. One might term it to be slightly slow in comparision with the industry adaption trend. However, our adaption was also driven by the needs of our clients. In the recent few quarters, we have suddenly observed that these platforms have now become main-stream. RoR/PHP is becoming a popular option in building the modern web apps whereas AIR seems to be the current ‘cool kid’ on the desktop side.

Adapting a development platform at the early stages of its evolution is always a challenging decision which an Engineering Head has to take for the product. I have always believed that adaption of any new technology is driven a lot by the herd mentality. Just because of the notion that many others are also using the platform, many a times the selection of a development platform becomes a blind decision. On the flip side, if a choice is about selecting a new platform – the same ‘herd’ mentality also comes in. The onus is more on the Head to prove his/her choice criteria rather than simply using the regular proven and established ones. Also, it is one thing to build up an experimental system using the new platform. However, the decision to adapt the same platform for engineering commercial products can be a hair-pulling one. Many a times in the end one has to finally depend on the two G’s – guts and gamble. Also the decision-maker will have to be continuously ready to answer questions associated with the hypothesis as and when any bad news associated with the platform (e.g. Twitter’s challenges attributed to RoR) or the product (e.g. initial breakdowns of the product) trickles in.

Because of the nature of the products we have been developing in my group, we felt that RoR was a very good platform choice for the same. So far (and I am knocking the wood here) our choice of the platform seems to have been validated based on the results we are seeing. It is amazing that how much dramatic productivity-related improvements these new platforms have made over the years as compared to some of the older generation-ones. I have myself observed this in my teams. Probably one of the big reason for this improvement is that these new platforms have started becoming very specific (e.g. web in the case of RoR) rather than the general purpose language platforms like C/C++, Java, etc. Dion Hinchcliffe in his posting “Creating Open Web APIs: Exploring REST and WOA in Rails 2.0” refers to productivity improvement numbers in the range of 10 to 20 times. Considering that programming time (or the development time) is the biggest cost of product development, the savings because of these improvements can be enormous. The built-in practices associated with Unit Testing, Agile, Reusability, etc. also seems to have aided in the aspects of building a more quality product.

Lately, the news about Twitter performance/uptime related challenges seem to have raised a lot of speculation on the run-time performance capabilities of RoR. While nothing has been proven as yet, such questions associated with newer platforms is enough to keep one awake in the night. Before jumping into RoR, I had in my mind that the run-time capabilities of these new frameworks would be weak in comparision with the compiled software platforms like Java, C++, etc. The above post by Dion has a good explanation about the same -

One is that the more popular, older programming languages tend to be relatively low level and general purpose and were designed for a different, older set of constraints. This has given us baggage that is often not very applicable to the modern Web-based world. Second, we’ve become very good at understanding the idioms and “syntactic sugar” that makes developers more productive for Web development and we’ve put that into the latest generation of programming languages and Web frameworks. Unfortunately, the combined newness of these new Web development platforms and their preference for coding time efficiency in favor of run-time efficiency has conspired to make the results they produce relatively slow and resource inefficient compared to what is potentially possible. Newness in this case is also a kind of performance tax since we just haven’t had enough time learning how to make these new platforms perform well at run-time, similar to early versions of Java before the advent of the Just-In-Time (JIT) compiler.

Based on the above and my experience until this stage – I am more comfortable in recommending these modern languages towards Consumer/B2B products as compared to telephony/banking transactional products. For the preferred products, many a times it seems like the advantages associated with improved developer productivity far over-weighs the slight runtime performance disadvantage these modern languages bring in.

Also my opinion is that it is too early to start comparing the modern development platforms with the older programming environments. Increased usage will drive the initiatives associated with the strategies targeted towards improving their weaknesses.

Thoughts, comments, and suggestions are welcome.

Add to Technorati Favorites

Tags:, , , , ,
Posted in Product Development | Leave a Comment »

Product Engineering approach for Startups (4): Estimating time and cost for Engineering of Version 1.0 product?

June 11, 2008

[This is fourth in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about why it is necessary to implement a Goals-Driven Planning Approach.]

My group – Version 1.0 in GlobalLogic reached a very important milestone this week. Using an unique business and engagement approach, we successfully rolled out a Version 1.0 of one of our first client in the group. This was done in-time and within-budget with all the quality requirements which we had agreed with our client. Two more products are in its way to be completed within the same parameters in the next few months.

I would not like to claim that we were the first to finish a project on-time or within a fixed budget. However the unique thing about this achievement was the approach and methodology we took to reach to this stage – especially when we had to consider the driving forces behind rolling out first version of a product. (fixed time to go-to-market, changing or evolving requirements, and most important a fixed budget)

We are currently engaging with more than 8-10 organizations who are keen in seeking our help in soup-to-nuts aspects of engineering and rolling out their product to its Beta. While each of these organizations bring in an unique vision and passion associated with their products, there was one thing which was common in almost all of them. Almost all of them – in our first meeting with them – were keen in knowing a ball-park number associated with how much time it was going to take to build their product and how much was that going to cost them. We had to tell most of them that in software world there was probably no formula or a calculator which existed which could easily tell them that. Well, unfortunately, at least we did not have one!

Having said the above, we also do realize it was also important for such product entrepreneurs to get a feel of the time/cost numbers before they jumped into their mission. So to all of them we typically have been suggesting the following thumb-rules.

  • Regarding time required to build a Version 1.0 = This, IMO, for a product at an inception stage should be same as when the product should be taken to the market. So time estimates to build the product should be the same as the product’s pre-determined go-to-market date/s.
  • Assume that it would always take x amount of time for one person to build up a product feature. Increasing the number of people does not reduce the time. So for example in 98% of the scenarios, it is not possible to reduce the time to build a feature to half if you have twice the number of people working on it. This is a very important aspect to be considered in software engineering.
  • It is a risky proposition to build the first version of the product on a fixed cost; it should be always built on a fixed budget. So the best possible answer associated with how would it cost to build a Version 1.0 of the product is typically best answered by the entrepreneur themselves.
  • You can assume fixed regular cost associated with the raw materials required to build a software (intellectual property, human services cost, hardwares, softwares, etc.)
  • Only variable which remains is the product scope which the product entrepreneur wants to be part of the Version 1.0 release. This is an important variable which the product entrepreneur can use to optimize time and cost associated with Version 1.0

Hope the above thumb rules helps in some manner with the estimations. As Sachin puts it very nicely – “There are two things any product entrepreneur has in abundance – vision and passion. There are two things which he/she does not have in abundance – time and money.” Keep that in mind while doing your estimations.

Thoughts and comments are most welcome.

Add to Technorati Favorites

Tags:, ,
Posted in Product Development, Startups | 3 Comments »

Designing a Product for ‘Repeat’ User

May 10, 2008

Let me first describe what I mean by ‘repeat‘ user. I think there might be a better term to describe this kind of a user, but the term is escaping me right now. By repeat user I mean the user of the product who has already used or checked out the product once and now is returning back to use it one more time. Hope you are able to relate to the category of product user I am referring to here. Almost all of us have been in this category one time or the other.

For the sake of this post, let me refer to the repeat user as Mr. X.

In my opinion and experience (both from the experience of engineering a product and also from being an end-user of the product), the perspectives of X towards his needs for the product are quite different as compared to what it could have been when he would have seen/used the same product for the first time. It is also well known and well understood that the success of a product – both from usage and commercial angle – is measured more from the repeat user perspective (and not from the first-time user perspective). I am not saying that the first-time user’s needs are not important. The requirements of first-time user needs to be understood well also because they are the ones who would translate into repeat users if things go well.

So what is so different from a product design perspective between the ‘first-time user’ and ‘repeat user’? First-time users are more keen on exploration. Repeat users are more keen on focusing on the regular functionality. A sophisticated design can certainly impress the first time user, however simplicity and ease is the key for a repeat user. As a repeat user for many products, if I were to quantify my usage, more than 75% of my interaction with the product is of a repeat type. Something which I have already done once and I am just repeating the same tasks again. My requirements from the product are now as to how it enhances my activity needs based on my usual usage patterns.

In my experience, I have noticed many product designers failing to think about the product from Mr. X’s perspective. Best products are those which keeps in mind the needs of this user. It is my strong opinion that in the end it is users like Mr. X who finally decide the fate of the product.

Add to Technorati Favorites

Tags:,
Posted in Marketing & Strategy, Product Development | Leave a Comment »

The Complexity of Status Reports

April 5, 2008

A colleague of mine and I were talking about one particular project where on average about 40 project/status reports were getting generated every week for management/team consumption. Both of us were astonished at this number. But the point which this colleague of mine made next was the real gem and hit the nail in the head. “What is the team trying to hide?“

It is amazing to see amount of time being spent by many teams today in just generating the status reports every day or every week. And the complexity of these reports logarithmically increases as the whims and fancies of the managers. These reports today have simple views, side views, top views, bottom views, and multidimensional views – all possible views. There are graphs, excels, powerpoints, etc. Even after all these plethora of reports, one VP Engineering I had talked to, said that by the time she sat to review the reports, her biggest challenge became to make sure that everyone were looking at the same version of the reports. The reports review just became a secondary activity for her.

I am of the personal opinion that the day-to-day or weekly report should not stretch more than answering 4-5 simple questions. All the other ‘crazy’ reports which I alluded to in the above paragraph should be restricted to the ‘Retrospection Meets‘. (Assumption here is that the team is not doing retrospection meets every day or week. If they are that is another criminal waste of time.)

Over the years, I have always wondered why are we today so obsessed with seeing regular reports. Investors are keen in seeing the company financial reports, CEO is keen in seeing the attrition reports, Engineering Lead is keen in seeing the feature status reports, while a QA Manager is keen in seeing the Defect Reports. Hell, even parents are keen in getting regular status reports from their kid’s schools. The more I thought about this and talked to various people about their needs on this subject, there is one thing I have realized. The need for reports is not for seeing the past (i. e. what has happened in the past), but more from the need of seeing/predicting the future. Predictability is the main goal here.

When I think about any project status reports (whether it is a project for software product development or completing a press release article), the key simple questions which any day-to-day status reports should answer are (this is derived from Agile Philosophies) -

  1. [Effort View] How much have we completed and how much is still left?
  2. [Size View] How much have been produced?
  3. [Schedule View] How much ahead or behind are we against the planned?
  4. [Risks View] What are the things which are causing/or could cause a drag on the project?
  5. [Quality View] What is the quality of our output?

The challenge for the Project Management Team would be to see if they can answer these 5 questions in about equivalent number of or slightly more number of reports.

Thoughts/Feedback/Comments would be greatly appreciated.

Add to Technorati Favorites

Tags:,
Posted in Agile Methodology, Communication, Product Development | 3 Comments »

Evolution of Workstreamr

March 27, 2008

Although few of us have been referring to Workstreamr in our blogs in the recent few weeks, the mystery around Workstreamr is now slightly clearing up. Stowe Boyd, one of the founder of Workstreamr, opened a curtain a bit more after he blogged about it yesterday. (Link – Workstreamr: Work Made Social)

I had started talking with Stowe Boyd, Sam Huleatt and Ben Schippers – the three co-founders of Workstreamr around the time of Diwali last year. (I will refer to the trio as SSB going forward in this blog). The first few weeks were spent in understanding the vision and the motivation which was driving these three guys. After about a month around the Thanksgiving time, my group – Version 1.0 – in GlobalLogic became the Engineering partner of Workstreamr and the actual implementation work started. It has been an amazing experience ever since.

One of the key focuses of SSB was to see how the social aspects of Web 2.0 can be used for fulfilling the needs of project-based work. Their argument (and I agree) was that the traditional project management mechanisms and tools in use today were built on older approaches which had an extremely linear thinking. For the sake of discussion here, let me call it “Microsoft Office” approach. In the Microsoft Office approach, Work items gets created in the Project first; they are distributed and assigned to individuals; individuals work and complete the work items. When all the work items are completed, the project is assumed to be completed. If things go wrong or unexpected, the whole process of re-calibration starts again. There is a ‘robotic’ feeling in this approach. IMO this approach simply fails in projects being completed by distributed teams.

As an organization, GlobalLogic traditionally has always been ahead of its time in adapting the modern practices in collaboration (especially associated with Web 2.0) within the organization. Tools like Wikis, Trackers, Instant Messaging, Bloggers, etc. are a common part of our day-to-day operations. (On the side note – I recently realized that everyone in my team is following everyone else’s work on Twitter). We call these as the “Productivity Enhancement Tools”. So in a sense we very quickly found ourselves aligning very closely with SSB‘s ideas. Also, having been in the Global/Distributed Product Development business for a long time now, we know that the needs for a platform like Workstreamr which facilitated the social aspects of collaboration and project management exists. IMO, I think this was a key ingredient for our successful collaboration till-date.

One of the powerful mechanisms which Workstreamr uses is the concept of ‘Streams’. Rather than one-on-one or one-to-many direct communication, Workstreamr pushes the concept of collaboration over ‘stream’ of information which individuals can subscribe, filter, or ignore based on their needs. Having said this, I understand that there are many other tools that are introducing the concept of streams in some or the other manner. Atlassian JiRA is one such example. However, the concept of ‘typed post’ which Stowe talks about in his blog is one of the big differentiator for Workstreamr.

For anyone interested in trying out Workstreamr, Workstreamr is taking in requests for registration for Beta at www.workstreamr.com (it is on a first-come-first-serve basis).

Along with SSB, my team and I are also very excited about how Workstreamr is shaping up.

Add to Technorati Favorites

Tags:, ,
Posted in Product Development | 1 Comment »

« Older Entries
Follow

Get every new post delivered to your Inbox.