Tag Archives: Product Development

Funding Product Development Teams

The project based funding model has been around for a long time and is an important part of the project management discipline.  But while the project based funding model certainly has its uses, the dedicated product team model has a number of advantages in the area of product development.  One of the main benefits is that it maintains team continuity, which is extremely important to turn knowledge and experience into successful product.

In a post on the Silicon Valley Product Group blog, Marty Cagan argues against the project based funding model for product development and explains the advantages of the dedicated product team model.

There are three fatal problems with the project-based funding model:

  1. You very likely have no real clue when you propose a project for funding if you should really even be pursuing the project.  Even though you might pretend otherwise with a cleverly crafted “business case” the truth is that you probably have no real evidence if your customers are going to like this, and you probably also have no real idea how much it will cost to build (because at the project proposal stage, you don’t even know what “it” is).  So you don’t know the revenue and you don’t know the required investment, so of course the ROI estimate is less than meaningful.
  2. Creating strong products is not a series of projects that come in sporadic bursts of a few months each over several years.  Strong products result from getting your concept in front of customers and rapidly and continuously learning and improving.  Further, to make this progress, you need not just continuity of investment, but also continuity of the team.
  3. Very often in good product work we find that our initial ideas are not quite right but if we change direction somewhat, which we call a “pivot,” we can often uncover major new sources of revenue.  These are the very sources of revenue that companies depend on for another several years of rapid growth.  However, with project-based funding, the consequence is that this sort of pivot is effectively discouraged.

You can find the article on the Silicon Valley Product Group blog here:  Project-based Funding

Incidentally, Marty has also written a great book about developing great products that I highly recommend.  The book is titled Inspired: How To Create Products Customers Love.

Recommended Books

Project Management:

Making Things Happen: Mastering Project Management (highly recommend, very useful and practical)
by Scott Berkun

Software Development:

Rapid Development: Taming Wild Software Schedules (reference for managing software development projects)
by Steve McConnell

Requirements and Use Cases:

Writing Effective Use Cases
by Alistair Cockburn

Software Requirement Patterns (useful patterns for documenting requirements)
by Stephen Withall

Software Requirements
by Karl Wiegers

Scrum Development:

Agile Project Management with Scrum (easy read, covers the basics)
by Ken Schwaber

Communication:

Crucial Conversations (for handling contentious conversations)
by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzer

* This has also been posted as a permanent page here which will be updated as new books are added.

How Theories are Built

Recently I’ve been reading the The Innovator’s Solution by Clayton M. Christensen and Michael E. Raynor, which seeks to analyze the process of creating and sustaining growth through innovation.  As part of it, the authors explain how predictable end-results of a process can be obtained by building a good theory.  This also applies to the software development process, where you must understand the process itself before you can make any meaningful recommendations for improvement and predictability.

An excerpt from the book which lays out the process for building good theory is below:

The process of building solid theory has been researched in several disciplines, and scholars seem to agree that it proceeds in three stages.  It begins by describing the phenomenon that we wish to understand.  In physics, the phenomenon might be the behavior of high-energy particles.  In the building of new businesses, the phenomena of interest are the things that innovators do in their efforts to succeed, and what the results of those actions are.  Bad management theory results when researchers impatiently observe one or two success stories and then assume that they have seen enough.

After the phenomenon has been thoroughly characterized, researchers can then begin the second stage, which is to classify the phenomenon into categories.  Juvenile-onset versus adult-onset diabetes is an example from medicine.  Vertical and horizontal integration are categories of corporate diversification.  Researchers need to categorize in order to highlight the most meaningful differences in the complex array of phenomena.

In the third stage, researchers articulate a theory that asserts what causes the phenomenon to occur, and why.  The theory must also show whether and why the same causal mechanism might result in different outcomes, depending on the category or situation.  The process of theory building is iterative, as researchers and managers keep cycling through these three steps, refining their ability to predict what actions will cause what results, under what circumstances.

Ensuring Success for Outsourcing Product Development

Since I’ve worked with an outsourcing vendor in the past, I’m often asked questions by those who are interested in learning more about outsourcing product development.  One of the questions that often comes up is how you can ensure that your effort to outsource product development will be successful.  The answer to this is in understanding your goals and the capabilities of the partner to help you meet those goals.

As with any partnership, compatibility is very important.  The first step to ensure compatibility is to understand what your short and long term goals are.  Is this simply augmenting resources for a short period of time to get a product out the door?  Or is this a multi-year relationship with a goal to reduce operating costs?  Both?  It’s important for you to understand what your goals are, as working with a partner who has conflicting goals is doomed to be a miserable experience.

Once there are agreed upon goals, the next thing you’ll need to do is select the development partner who will help you meet those goals.  You want to make sure that the partner is a fit, which can be done by putting together a list of criteria that will help you assess this.  By having this criteria, you’ll at least ensure you’re doing your due diligence to find out as much information as possible for the most compatible partner in all aspects of your business.

Here’s a list of selection criteria I’ve used in the past (in no particular order):

  1. Communication: The partner development team needs to be able to communicate clearly and articulately, through both written and verbal means.  Project and other meetings should be during normal work hours (ideally), and you need to have an understanding of the method of communication (teleconference, video conferencing, etc.), frequency, and proficiency in the native language of the development team (how easy will it be to communicate with the core development team?).
  2. Onshore Alignment: Are they willing to spend time onshore with the team to understand the project and our development?  This is key in reducing miscommunication early in the project.
  3. Infrastructure: The infrastructure of the partner company has to be mature enough and stable to support your development efforts (what is this company’s experience in this area of setup?).  This includes internet connectivity, VPN, and telephony services.
  4. Cultural Differences: There should be some type of awareness of this by the partner company.  What are the cultural differences?  Is it compatible with your organization or will it negatively impact your projects?
  5. Software Development Process: This is the maturity level of the software development process (including testing).  Is it documented?  Is it repeatable?  How will development and testing be transitioned back within the onshore team (if needed)?  Can they align with your process?
  6. Individual Contributor Knowledge & Skill Level: Your partner must have the right level of knowledge and experience for the individual contributors.  Can you interview their people to make this assessment (Development, QA, and Program Management)?  Are they willing to pass a technical challenge to assess this or take on a smaller trial project?
  7. Staffing Time: What is average time to staff a team when it is needed?  You need to know the number of contributors available at any time to be “called up.”
  8. Performance Issues: How are performance issues handled?  Can you turn away individuals who are not performing up to expectations?
  9. Management of Engagement: How is management of the project (and overall engagement) structured?  Is it inline with what your group needs?
  10. Project Monitoring and Controlling: How will you have “checks and balances” of the offshore Project Manager?  What processes are in place for guiding on time/on budget delivery?
  11. Employee Turnover and Motivation: What is the level of employee turnover (any guarantees against employee loss)?  You will probably want to build knowledge within the offshore team, and if team members are constantly changing assignments this will not happen.  How are these individuals motivated?  Is it inline with your group?
  12. IP protection: Security for your work.  How can you be assured that your development efforts will be secured?  What kind of infrastructure security does the partner have (keycard access to only necessary employees, physical separation from other operations, 24 hour security guards)?  Security process?
  13. Business Measurement: What measurement and metrics will be used to ensure alignment with your goals?  What is the number and percentage of successful projects on time and budget?  How much money is typically saved?
  14. Resource Costs: What is the cost of resources based on skill and experience level.  Is there a rate card?
  15. Similar Projects Success: What other companies has this vendor delivered for?  Are the projects similar in scope and complexity?
  16. General Engagement/Project Size: How big is the usual engagement?  What is the general project size?

By understanding your goals and assessing how a vendor can help you meet those goals, you’ll give yourself the best chance of having a successful partnership in outsourcing your product development.

Managing Projects Out of Crisis

Project Manager Dealing with Crisis

Note: This is slanted towards technology product development.

Short post today around thoughts about managing technology product development projects out of crisis.

Whenever I have come on board projects in the past that need course correction, the first thing that needs to happen is to level set on where we are in the product development cycle and ensure that we have a plan in place to deliver.

This includes documentation/design around major features (to ensure we understand how we will be implementing and that estimates are as accurate as possible at this stage), a list of risks built by the team with priority/mitigation/contingency, test plans to understand how we will be executing on validating the product (among other plans, like operations), and an analysis of when we might expect to meet the release criteria.

It seems simple, but we do not have a plan if there are approved change requests that are not included to be executed.  Scope and resources should be set before we can be fairly confident that we have a plan we can execute successfully (of course schedules aren’t necessarily “set,” since they are probabilities).  Product Management must also understand that it will require discipline to ensure that no unnecessary change requests are added to the plan (there will always be change requests, but we need to make sure that they are important enough and reach a significant number of users to be worth the delays).  In general, the entire team needs to be focused on shipping the product.  QA Engineering could always ask for more time to test, Development could always refactor or implement a cool new technology, Product Management can always ask for more features, etc.

The entire plan to deliver on a product should already include the late-arriving features, and thus at that point they are no longer “late-arriving” but part of the plan.  There should also be a risk buffer built into the schedule to accommodate the realization of risks (which stakeholders should be aware of), and each team needs to be accountable for their commitments.  Anytime a risk is realized, the stakeholders should be aware of the time that is being eaten out of the buffer.

Of course, managing a project out of crisis isn’t only the job of the Project or Program Manager.  I would also put my most experienced Development and QA leaders in charge of righting the ship (if they aren’t already) on both sides and ensuring that the Development plans and QA plans are the right ones and are being executed.