Which way out? - The Importance of Exit Criteria

One of my fundamental criteria for starting a new product release is being able to define the Exit Criteria.

As a rule of thumb it is being able to answer the following five simple questions with accurate and complete answers (the questions are simple - the answers less so ...)

1. WHAT? - What are we building? What the key features and product values that the release will deliver?
2. WHY? - What are the key benefits that the customer will derive from the product when it is released? What are the values and advantages that the release will bring to the product family/company?
3. WHO? - Who needs the product? If this is a release for the market then define the customer - specific accounts or profile the type of user that the product is targeting. Also state who will help with the necessary integrations, GTM efforts and other internal stakeholders. If this is an internal development effort then who is the internal sponsor and who is tasked with supporting the integration and deployment.
4. WHERE? - Where should the product be delivered? Describe the internal or external deployment scenarios and any pre-requisites that will make the difference between a successful launch and failed one.
5. WHEN? - What is the timeline for this release? When must the product be in the marketplace or delivered internally? 

Once defined these criteria should be critically analysed to ensure that they are coherent and meet the SMART (Specific, Measurable, Achievable, Relevant & Time-bound) criteria. Will they meet the overall objectives? Will the product as defined meet customer expectations? Is the product definition correct? Can it be delivered in the time-available? Is the target customer the correct one to achieve the overall aims? Is the target environment feasible. Answering these questions will often force a rethink and changes, but should result in a clear definition of expectations. The entire team can adopt the final definition adding purpose and clarity. It is also critical in managing any changes that maybe needed during development


Overall the Five W's set out to define what does the product need to do, by when in order to make somebody very happy?

In my experience this is an iterative process, but, answering these five simple questions adds significant clarity to the product objectives and can make the difference between a successful product and a poor executed product that takes significantly more time and resources to develop and then fails to deliver most of what was expected.

Being Customer Passionate

Customer service with passion makes a difference.  You can feel it. You know it when you get it.

An example -  my company recently changed cleaning contractors; you know the people in blue uniforms who sweep and clean and who seem to change with alarming frequency . (A small digression;  they make a huge difference to our lives and you see them every day so be friendly and grateful to them a quick hello is really appreciated.)

The new team are pleasant enough as people and seem to be full of activity doing the regular cleaning stuff. They sweep, their managers buzz around and they all fill in the standard inspection forms. So seemingly all is well. However, actually things are just almost OK, but are certainly not to the right standard. The floors don't quite sparkle, often there are shortages of paper and unexpected messes seem to take a long time to be cleared.

On our floor the old contractors had a super team. As far as I could understand (they were immigrants and we didn't really have a common language) they were actually a husband & wife team.  

What is for certain is that the worked very hard and cared for our office just like it was their own home. They did extra inspections and made sure that everything was just right or even better. I am sure that our toilets and kitchen were as clean as in their home. They cared- actually they really cared and they had pride when you showed appreciation. Some other company now has their services and is very lucky - Anna & Anatoly come back we miss you!

They were true cleaning professionals and worked from the heart and it really showed. The new team just do their job and that also really shows. We all appreciate people who are customer passionate.

We need that professional passion in all our products - that is a difference that the customer notices. It is true differentiation.

The Value of Business Value

Business Value is often the holy grail of Product Management (and rightly so) especially when working in Agile.

Business value is genuinely very important; product managers are tasked with building products that offer some real value to somebody. Business values impact almost everything that we do with our product - its positioning, its go to market, its roadmap and its customer centric focus. These core elements of the art of product management are derived from and driven by the business values.

Classically we build things that people want to buy, advancing the business plan of our company. In other cases we may be trying to build infrastructure or experimenting with some novel ideas. However, in almost all cases we can define the objective with business value even if it is a stage or more removed from an actual sale to a customer. I plan to explore business value in these indirect cases in a future post.

So given that business value is one of, if not the primary objective of our professional lives it seems surprising how little attention many of us pay to the business value. Sure we read and write documents with some lip service to the business value. When we do a kick-off meeting we feel forced to generate a couple of statements on the subject and every so on a senior manager will feel the need to talk to even more senior people and have a mini crisis trying to generate a set of business values across all the products that they sponsor. It is possible that this is mainly a feature of big organisations; but my suspicion is that it is a common feature. It is more fun to build and design than to make bold declarations of future business value.

The crux of the issue is that it is really very important and on the critical path of everything that we do. If you are lucky enough to be constantly customer facing then you probably have a pitch maybe even several for different segments, but for the rest of us it is rarely on the agenda.

So here is an idea that I plan to put into action tomorrow - to have a slide deck or excel or some other file with every product that I manage together with its business value. So far, relatively easy, now for the hard part -  to try to keep it updated - say four times a quarter. At most reviews I think it will just be a critical read through and add the review date; but every so often things will change.

I think that this exercise will help in a few ways -

• We will really understand why we are building the product
• We will be able to remain true to the objective and not get inadvertently side-tracked in the natural drift of a dynamic product
• We will make any necessary changes actively after due thought 
• Of course finally we will always be able to provide answers to anybody who needs to know right now

Optimal Length of Agile Sprints

Agile is a popular development methodology sometimes it seems to be the only method in use today.

At the core of Agile is to break work down into small chunks that can be managed by the scrum team in a short period of time known as the sprint.  Ideally the sprint delivers some or several useful functions that can be shown (demo) to stakeholders and ideally to customers in order to gain feedback and to change and improve as quickly as possible. This objective is often to deliver MVP or Minimal Viable Product although this is in our experience often beyond the realistic scope of a single sprint.

The idea is that the team commits to a given quanta of work that can be experienced by the customer and get quick feedback. It also allows flexibility to change direction or priorities of the overall development.

In our organisation one of the big questions is the ideal length of the sprints.  

To set the context most of our development does not get released to customers on a one or two sprint basis. We use sprints as a meaningful checkpoint and as a way of involving other teams, stakeholders, sponsors and management.

Previously we used three week sprints and in this specific business unit the custom has been sprints of two weeks.  We are now in the process of moving to three weeks; partially at my initiative.

The reasoning is that two week sprints are valuable when the output does get delivered to users and especially if it is user interface rich. Fast work and rapid feedback and intense market dynamics seem to fit in this context.

However for work that develops over time especially with a lot of infrastructure or core development then there are many disadvantages to short sprints.

Agile sprints have high overheads in each and every stage of  preparation, execution and post sprint analysis (Discovery, Pre-planning, Planning, Retrospectives etc.) There is also management overhead in driving an organisation with several projects each with short sprints and low capacity. Overall these overheads that amount to high costs that the organisation can not afford over time. Longer sprints have lower overhead and so are more efficient. Our analysis indicates that moving from two to three work sprints cuts most of the overhead linearly.

Shorter sprints present a challenge in trying to deliver real value (MVP or MVP-like) even more so if the team is quite small. It is perceived that the small capacity presents its own challenges in preparing and planning the sprint trying to customise the business needs to the limited time.

Another critical issue is the vulnerability to planned and unplanned absences. It only takes a couple of days vacation, course or sickness to wipe out the content of a sprint. Bugs, tricky integrations and environment issues have a similar disastrous impact.

Finally, short sprint cycles place a large demand on the Product Manager and his team. The cycle times are so short that there is never any time to pause and consider the bigger picture and to research new ideas and future directions. Again we think that there are almost linear savings available by increasing the sprint length.

Overall short sprints are considered expensive, hard to plan and prone to delay. Our analysis indicates that three  week sprints are a better balance of flexibility (Agility) and efficiency.

Working from Home - Why Yahoo and all the old fashioned companies got it so wrong!

There has been a lot of news and comment recently about Yahoo CEO Marissa Mayer's new policy of requiring all its workers to work from the office. People have commented that perhaps this is a way of "right-sizing"  the company. Apparently many of the workers are pretty much permanently working from home.

It is a subject close to my heart - I used to work at an organisation that was very much mission orientated - even junior managers applied large amounts of discretion when people needed to work from home. Indeed it was frequently a management tool - a solid day at home can accomplish quantities of work that take weeks in the office - for example in preparing a design document, strategy or any other thought intensive task that is frequently disturbed at work!

Talking to friends it seems sadly that many organisations are becoming more draconian in their outlook.

I do agree with the statements made by Yahoo that meeting colleagues known and unknown is a fruitful process that generates cooperation and ideas. But, let's be honest it also generates useless conversation about last night's sport, next weekend's plans or the state of snow on the ski slope. Clearly, these are important human interactions that make life and work more pleasant - but, they can be missed occasionally in the interests of concentrated work.

I also think that managers need to cleverly manage their workers wherever they are located to get the best return on their investment - this is probably "easier" in the perception of many weak managers if the worker is chained in their cubicle.

However, I am a firm believer in the value of working from home.

First and foremost, our workers are the key differentiator that we put into our products. In return for asking them for the extra commitment to make a real difference; this means being sensitive to their needs. If I need them to put in extra time to simply make it happen, then I should allow them to do so from home (assuming no security concerns and practical issues.) In addition, if the same worker needs to spend time at home a few days later with their kids, getting the washing machine fixed, or just to avoid rush hour commuting then I need to offer (within reason) the same flexibility that I asked of them when it was convenient for me. My employees will only go the extra mile if I understand that there is a two way process - or if I pay them so much that.... but this is not going to happen! (In fact it is almost impossible - we always want more.)

I need to trust my workers - their potential to do damage with poor product design, a mistake in front of t he customer is well above their hourly or even annual wage. I need to train, encourage and trust them as their manager - so if I trust them with a few millions of sales or company assets I can probably trust them not to fiddle a few hours of timesheets. Guess what - if they under perform then I need to correct and perhaps eventually fire them - independent of where they work. I need to give them clear productivity targets and KPIs and the tools and the guidance to achieve on time and with high quality.

As their manager I need to develop a greater skill set if they are not down the corridor, that is a challenge not a threat - I will be a better manager in a whole variety of ways and circumstances. In fact I need to show then my leadership and not my weakness.

We live in the twenty first century! This has many impacts. It wouldn't do any harm at all if companies reduced their carbon footprint by saving commuter travels. By the way it saves them quite a lot - if this is a company car then there is a direct saving in fuel and clever use of corporate space also cuts down on rentals, heat light etc. This can be serious money.

There are other elements of the 21st century that impact the debate. There are endless amounts of technology and products designed just to make it possible to work in teams even remotely. I know this, because all companies I have ever worked for expect us to use these technologies when we are traveling for business. Late at night, jet lagged and exhausted we try and keep up with the "day job" just so we don't get too behind and stop other projects because we are not around. On the other hand, sadly in the 21st century there are plenty of distractions in the office. Poor workers will waste their time and those of their fellow workers only too easily. Our job is always to challenge them to do better.

Working from home removes workspace distractions - no sport, no accidental team sessions by the water cooler, no pointless meetings where nobody is very clear why we are meeting and what we plan to achieve (apart from discussing current events). Most importantly it provides the space in time and place to really get some concentrated work done and hit my targets.

So in short - working from home can have tremendous upside in terms of worker respect and work achieved. It can also save the company substantial expenses and increase employee happiness. Sure it can be abused and sure their are distractions at home - but we need to judge each person by their results and not by corporate dogma. As managers we need to recognise that like most things there are pros and cons and that there are different people out there with their own needs and their own contribution - we need to work with our teams to make sure that we get the most from our policy; it isn't right for every person in every job function every day - but it works for many people in many situations.

We need to embrace working from home for our good, the company good and for the good of our fellow workers.