Why is product manager important to a project?

Background

As a project manager I see all to often what I like to recognize as human nature - our drift to start projects, kick off ideas and just try something out. This is often a very commitment-free stage even in large projects, when ideas and upsides, win-wins take turns. 

From this point we all to often just kick off the project and start planning, implement, buy what we need to get it done. But will it cut it when it comes to major investments? 

A project is defined to have an end, when it will deliver a "product". The product will then live on and make money, bring joy or what the intention was from the start. If the project means major investments  - can we afford kick off, run, release and once something is ready kick back or start with something new?

Yes, a project manager will say since it is a kick-as product. But, the product owner must be equally committed. It is, again, the product that will generate revenue how the product will be used, maintained, supported etc and by who *must* be handled with as much enthusiasm as the project it self.

With this post, I want put focus on this and hope, if you work with product development, understands and put some extra thoughts to this and maybe it can save some nuisances down the line.

There are two major pits you can fall into and it is common that you do.

1. During development of the product, i.e. the initial project. Here it is so easy having only a project manager driving the project deliverable and business decisions, product plans etc are shared between either the project manager or managers that are stakeholders to the project. The lack of not having a dedicated product manager that understand and is very committed to the business of the end product will make the ownership of the product be vague/divided and often ends up at very high management resulting in rather long turnarounds of decisions and other actions needed.

2. Product life cycle vs project life cycle. Those cycles are very different, putting product management tasks on a project manager will make this obvious. A project managers main deliverable is to deliver a product, there will be optimizations and mitigation's made to reach this deliverable - all those optimizations need to objectively consider by a stakeholder with product life cycle in mind. If an optimization is made to save $/time early, it can very well cost much more down the line when thousand/millions of the product have reached the market.

The role for avoiding above pits is the product manager, it is mentioned in many processes but is not as often used. Without the role you will have a leak in the continuous development loop and the product (which should pay your salaries) is once release from the project left on its own. A product managers work will at this stage continue since she has been involved on all decisions that have impacted the business during the project and will now ensure maximal lifetime payback. Decisions made in favor of releasing product quickly will show if it was worth it, marketing efforts will hopefully pay off and product update plan should be more or less settled. A product update plan will in many cases require new project(s), in some cases it will be handled by the same resources who made the initial release but in some cases much or all of the staff is replaced if so, the product background is only with the product manager. The update plan is also made with the pay back in mind, meaning a costly feature release should be weighed towards a cheaper quality release, will the added features increase the sales or is it more important to handle flaws to reduce returns.

Reverse planning

In many cases projects starts with a rough idea of the scope and a rough a idea of a deadline. Depending of the size of the project "rough" means different things, but lets say the project is about 2 years, then the deadline is probably during a quarter.
This rough deadline is quite quickly getting cemented at the end of the quarter. I will not debate in this article if this is sane or not, just stating how it often works...

Given this and the rough idea of the scope, that probably is a large part "must" and a small part "nice" (part of the "must" is probably negotiable as well since there it also common to miss-use this term).

Since 2 year is a long attention span, much to long for humans to grasp, there need to be passages where your project needs to pass. Many project models has them:
- Tollgates, mainly used to secure fundings. I.e. we have achieved this, as we stated and need this additional funding to continue.
- Milestones, project achievements.
You can also call it a Checkpoint, might be similar to MS, but can be used more freely as both internal o external of the project. Agile methods adopt this to deliveries in short intervals.

If you do not have these planning cornerstone - get them. Once you have them in your sight, the hard part (planning wise) start -> what should be ready at each MS, CP TG...
If you have TGs and MS, they are probably already defined but not necessarily very frequent hence I will not spend much time on those here. If you have them, there is achievements required i.e. you can/should consider them as a deadline.
But, as mentioned, MS and TG can be very infrequent. And in projects, when velocity is needed, you need to keep deadlines in reasonable sight - introduce Checkpoints. By introducing them, it will generate some overhead to define and following up but that is a crucial step in gaining velocity, only drawing them in a time plan is not enough (similar to planning frequent releases in scrum but not follow them through does not make it agile).
At each CP (or Scrum release) you, aside from reflecting on achievements, you also plan for the next CP/Sprint and re-visit the final plan. But working actively at these stages will enable you to grow more confident of what you will deliver when.

I guess most of this can be found in many how-to-run-projects articles and project models etc, but I want emphasize the active work that needs to be done at frequent intervals in order to gain the benefits.

Agile methods when developing SW to new HW products

[Background]

I have for a few years working to apply agile SW development to product development, i.e. creating a HW product with SW from scratch and will try to summarize several of my findings.
Some basic facts/findings (in this case):
- Producing HW, prototypes etc cost more money than a SW prototype (a lot more)
- Turnaround time for HW changes are a lot longer than SW changes. A product have typically <10 builds from scratch to complete product, during a span of at least 12 months. SW have more builds made in one day...
- Agile is not equal to Scrum, scrum is a well known toolbox but you do not have to do scrum to be agile...
- When a HW prototypes is build, it is most likely planned/purchased timeslot and what is not working when the slot is at end (on the HW) will not work until the next build is scheduled.

Software on the kind of products I have in mind, can be simplified in 3 different categories:
1. HW level, typically SW that is used to communicate with sensors, drivers and combining data from those. This level is the foundation, both upper levels of SW as well validating HW components, both during production and developing prototypes
2. Middle level, typical level of SW that is highly dependent on running correct HW and providing the glue to present a usable product.
3. Top layer, typical different add-ons that will enhance a product that can be added/removed quite easily to a product. Can be developed, if design rules are in place, on different HW but need to keep performance and other restrictions in when doing so.

[The differences]

On top level, sw can be developed very similar to pure sw project, there are deadlines etc but most sw can be developed on emulator or different hw.

The other levels have a much deeper relationship with the hw, meaning the development must be aligned harder with developing hw and following the deadlines it have. Two main reasons, building a hw can cost a lot of money and takes much longer to correct mistakes. The priorities, business value must focus on enabling use of hw when this is needed. A common mistake is to set all business value is something end-user will go wow about, I.e cool features that will be noticeable instead hygiene factors, but you-must-secure basic functionality first, if this is not covered - there is no need to look at the wow-factor. 

Sorting this out is hard work for a product owner, since understanding end-user need is different from understanding the process of developing hw, meaning it is often made by different persons different organizations even.

[What to do]

As for all other project, it needs a product owner or champion. With a product owner I mean an appointed person with the assignment to make profit of the product that the project produces. The product owner will have final call if needed of what should go into the product thus, a product owner has enough knowledge of both HW and SW to know what is more important.
Without this role or if the role is distribute to different organisations all projects will end up with misalignment of resources - stronger part-project-owner will sell their part better and draw more resources to this. If this is upper layers you will end up with lots of people wanting to add cool stuff (most really good), but not enough to make the basic features work in a timely manner. This will not happen overnight, it will grow on each organisation and settle as an accepted way of working. At this point it is both hard to realize you have a problem and even more so get out of the habit.
There are probably a million reasons to why it ended up in this situation, but if you realize you have a problem your main focus should be how to get enough authority to one product owner instead of finding the reason to why it went south. Some might argue that you need to understand what and where it went wrong to be able to fix it and in most cases I agree, but on this very complex situation where you might have several stakeholders that claims that they are the main owner of a part of the system, some even stating they own it all (except some parts) you are more than likely to have a very established blame-game in different levels. An establish blame-game will never reveal a true point of making the wrong turn, it is more likely to tell you that there is not really a problem (not in "my" parts anyway)...
I realize that this might seem out of bounds when it comes to agile methods so let me clarify. When you start with agile methods it very easy suggest to have self containing teams, i.e. teams decide what to do themselves which is part if the setup. However, when a team is part of a system there is another governance that overrules on some levels. It should also be clear that I do not mean that the higher governance aims to control teams in details but to take a wider responsibility of what needs to be done.

[How do you know if you are in problem]

- Is there any question to who owns decision on what should be included in a product?
- Is there any question to who owns decision on what should be included in a project?
- Is it a common reply when poke in a problem that "this is not my area"
- Are there more noise from teams that want to deliver, but it is not good enough to deliver to, than from teams delivering
- Do you get a feeling each time you present a problem, several stakeholders release their breath when they understand it is not "their" area?
These are some question you can ask yourself, if it is hard to come up with a answer there might be more to find.

[Summary]

I am not sure I managed to stay tuned to what I intended with the post when I started, but let me try to summarize.
- It is very easy to translate agile sw development to run fast with little plans, but this is wrong. You always need to plan enough. And when involving build HW it almost always comes with a lot more costs - the SW that HW has dependency to on need understand and agree with HW development what is needed when. After this, feel free to use any process you need. Agile methods are in many cases even preferable.
- Projects always need a product owner, i.e. a stakeholder that will receive the finished product from the project and be continue to work with the product, producing units, requesting new projects to improve, requesting running changes of the products etc.

Analyzing a problem - what should be solved - really

As an engineer you are probably very skilled at solving problem and in many cases it might even be a passion to you, which is good. However you need to be a bit picky about what problem you should solve...

In normal daylife with simple problem there is no need to think - just do it. If you have a flat tire - fix it, etc. But often a problem will aquire some effort in fixing then it is always useful to do some kind of analysis to make sure you understand the problem and focus on a root-cause instead of a symptom. My favorite tools for this analysis can be found here.
http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000
Also good example of focusing correct
Problem: Smoke in room
Solution: Open window

Or, with some more effort
Problem: Smoke in room - <so what> - hard to breathe - <so what> - will pass out shortly - <why> - smoke form sheets - <why> - cigarette burning, laying on sheets - <why... wait, what??>
Solution: Put out cigarette, make sure sheets are not on fire, open window

Meaning, make sure what/why it is a problem and then make sure you find the root cause and then solve. It might not even be a problem, you could be at a disco with cool smoke coming toghether with strobe light...

Performance feedback to team members/co-workers

As a Line or Project manager you most likely get involved in evaluating people. As Line manager - you need to gather information from other about your direct reports, as a project manager you are often the first contact of a line manager to give feedback about your team.
As a general rule, but not often applied, I suggest that both Line and Project managers should keep some kind of diary where short notes can be added of the team - this way you will have a good draft ready once it is time to make it official.
For Line managers, to get the complete profile do not just ask project managers or people leading your direct reports but also peers and if available, people who is reporting to the person being evaluated. Also, keep focus on open questions instead of Yes/no questions - it is important to get a wide picture before you narrow it done to your perception. When this is done you need to consider what baseline each report is referring from, i.e. are there any comparison.
Key topics to get elaboration on for each co-worker can be used by a line manager when preparing the questions also guidance to whoever get assigned to evaluate someone else.

For project managers, you should take time and keep notes as suggested above otherwise when you are asked you will base your review on very recent events and/or only major events. Remember this another tool to help your team to evolve as well as a good opportunity to sort out what you really need from a team. There is of course a valid point to go through your thoughts with the individual directly, having a healthy dialogue will probably gain some feedback as well.

Role description of a Project manager

As described in previous post I was assigned a small task to write a role description and published a few thoughts on it. Now I have written it and here are my findings/suggestions:
- Make sure you understand what is expected by the role from "outside" - do not only rely on what is the current work tasks at hand
- Formalise the expectations/output
- Based on the expectations - create the major task-groups with a sane level of details
- Based on the tasks - what input is needed, and a rough idea where this information is available.

I.e. write is from the end to the beginning, and make sure to have a review after each step. Doing it this way you will stay tuned to expectations and need, if you start with with the input/info available you will likely create tasks and output based on that instead of need.

This can and probably will put light on information that the role is depending on but no clear interface - note them and request them to be address of whoever commissioned your task. The avalanche has started...

What is expected in a role description

When you start a new assignment or a new job you might encountered "Role description", a document or similar that should describe what you now are expected to do. I am not sure how important it is in the long run, since reality changes more often than the description - chances are that it grows obsolete. At least in projects the outcome are more depending on a team effort than a bunch of "sandboxes" with defined interface doing what is expected.
A document to help you get familiar with some basics will be helpful, but so will a introduction by a experienced person. Of course a introduction followed by some version of mentoring will always outweigh any documentation but that requires time and commitment from mentors. And to get that effective would require guidelines to potential mentors, i.e. what needs to be address during an introduction etc.

So, who should the description help. I recommend that a description if firm on what is expected by the role, and more vague of close interfaces. This will get the benefit of being clear on what is expected and will get an attentive person driven to clarify what she needs to succeed.
This kind of description will probably stay more up to date as well as it have less detail on what is owned by others. It is also useful for any mentor as guideline, if the organisation have opportunities to have mentors - updating and maintaining the document would be a given task for them.

This how I address the current description I am working - and intend to publish a bit more details here once I tried it.