Search This Blog

Showing posts with label team. Show all posts
Showing posts with label team. Show all posts

January 14, 2015

Get the Design Right Before the Start of Development

We are currently working on a data intensive product. We have a great team - top class developers and team lead, a great system architect and I hope a pretty good product manager. The requirements are well understood and we received a well researched specification from the project sponsor. We are working using Agile and although this is a start from nothing project we produced some impressive user flows with demonstrable value even in the first sprint.

So as the product guy I am very happy and keen to demo the product to anybody and everybody.

There is, however, a problem. At almost every Discovery meeting, after every daily and at working meetings in between we change the data model, just a bit to tweak it; (almost two sprints into the development.) I have tried to analyse the situation and reached several conclusions. I don't think that we are tweaking it just for the pursuit of perfection. Almost all the changes are because there were some soft areas in the requirements and because the model isn't yet fully functional. I am sure that in another couple of weeks we will have resolved most of the issues and things will reach some equilibrium.

Secondly I think that the discovery team and developers are so switched on and involved that we are really working the topic. We get involved and we have opinions (and the problems are quite involved and tricky.)

As an aside; this intensive (re-)design method leads to uncertainty, the changes are so intense (and actually quite subtle) that the documentation is less than perfect. Partial explanation is found in different user stories with open editing rights. This makes things just a bit harder for the team. There is plenty of readjusting and rewriting.

My last conclusion is that in this project we needed a more traditional approach that involved a full system design that was analysed, debated over and clarified for a (hopefully short) period of time before the first line of code was written.

A stable well defined design at the outset would have saved us a lot of time, debate and on the fly design and development. It would also have improved the communication and stability through better design documentation.  I am sure that we would have missed a few points, but then the Agile method would have allowed relatively small and painless corrections.

I think that there are many products where more forethought before starting the sprints will lead to more efficient implementation (and necessary corrections) in the development phase, It isn't always easy to do this - often the requirements are still in development or there is pressure to start work, and perhaps in subsequent releases where the changes maybe quite small relatively it isn't even necessary. However, I think that it is a valuable question to ask when initiating product development can we improve the design before we start work? There is a subtle balance to be achieved between over design/slow customer interaction and impulsive coding/multiple revisions.

February 27, 2013

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.

January 5, 2011

Be A Better Speaker - Tips from Steve Jobs

As PMM we are all often called upon to make presentations or to speak. We need to enthrall our customers, motivate our team and convince our management (or sometimes we need to enthrall management, convince the team and motivate the customer.) Effective communication is part of our day to day activity.

So we prepare a few slides, work through our basic arguments and stand up. I once went to a customer meeting and whilst we were waiting in the lobby my colleague was still busy making changes to the presentation - let's just say that overall that meeting was not our finest hour!

We have discussed some of the common mistakes that happen; even at a relatively senior level, and I also shared a neat time limited presentation style. In this post I want to share a few insights from one of the world's communication masters - Steve Jobs. Most of the key information can be found at this link from Business Week - watch the video and the slide show - well worth the time.

So a few thoughts from the master -

  • Jobs prepares his story thoroughly and apparently unlike most of us a long time before he opens Powerpoint
  • He focuses on the benefits and engages the audience by showing them why they should care
  • Jobs is brief and succinct and also he breaks his pitch into 10 minute sections to stop boredom
  • His slides are elegant and often devoid of all words - he captures you with his visual images
  • He sells dreams not products
Some of these concepts are hard to implement in a mundane meeting discussing the finer points of our design which seem far removed from a vision, but with some effort they can make all the difference.

It has just been announced that Steve Jobs has had to take a second period of medical leave. JET wishes him a speedy return to health.

November 14, 2010

Product Management - The Longest Race - Part 2

In a recent blog (here) I discussed the product management and marketing lessons that could be learnt from the recent Nike 10K night race in Tel Aviv. I discussed the event planning (impressive and complex) and the event objectives (which were probably significantly more than just a fun run).

In this blog I will discuss some of the results of the event.

As a runner I can say I had an amazing time, and that on the whole this was an impressively run event.

However, the main question is what did Nike think? What KPI's did they set in advance for the event (number of runners? low number of problems? set up/clean up time? News minutes? Facebook group members?) Were their targets met? More importantly were the targets the correct ones or were they chasing the wrong things - were they were focused on their own issues and not on being customer centric?

During the course of the race itself there were other aspects of product management in action. Every once in a while there were music and water stations, we can consider them to be product features, helping the customers to enjoy the experience more, to engage with them - what will make them happy customers that will come back next year and recommend to their friends?

On the assumption that they plan to run a similar event next year, how, are they acquiring data and how are they planning to review and improve?

On the subject of next year we can consider product extension; will they feel the need to enhance the offering - perhaps by offering a shorter or longer version or by diversifying into a cycle race or triathlon? Perhaps there is a market for more than one event a year?

There were strict rules, we were all supposed to wear the official race shirt and run the course in an orderly manner. There were a few people who ran but I guess hadn't registered, and so ran in their own shirts and there were a few who wanted to stand-out and so ran in other shirts (last year's race etc) - on the whole this caused no problems to the runners. However, we can certainly view them in the context that the product was excellent, but, that it wasn't perfect - it was fit for purpose. Of course, since we mostly followed the rules, then we were complying with a certain standard, specification or protocol.

The race had a strict delivery schedule - it had to be ready on time and it had to work adequately well on the night. So part of the secret here is in team work and execution. The PM&M can have designed the perfect race, but if his project team didn't get the water in the runner's hands or publish the results then the product experience would have been irrevocably tarnished in the eyes of many of the customers.

So in conclusion I had a good run that evening and I believe that the experience was shared by the vast majority of the runners; I suspect that Nike felt that it was a success, but, that they have some points to improve or change in the next year. Overall this was a fine example of the craft of product management and marketing.

More importantly, I hope that by looking at an event that is outside of our day to day we can see the implications of strong product management leadership on all aspects of product design, management and marketing in general.

November 12, 2010

Creating a Product Road Map

“Follow the yellow brick road” - this is the instruction that Dorothy got in order to get to Emerald City.

Product managers are responsible for building the product’s yellow brick road – the Product Road Map.

The road map generally should normally be planned for a 3 year period at a high level and for 18 months in a more detailed manner.

Probably the most important starting point for the road map process is the outcome of the strategic business process of the company. This is a critically important process performed periodically (often annually) by the senior management of the company together with the marketing team and actually drives the entire company. When we start to create or update the road map the last version of the strategic process is a major input.

Often this will be replaced or supplemented by a product strategic process where we systematically look at all aspects of the product and the market and set key business objectives within the overall corporate strategic framework.

The road map process starts with information collection which should include the following:

  • Market trends
  • Regulatory trends
  • Technology directions
  • Competitive analysis
  • Customer requirements and suggestions

In the next step we need to analyze what is the likely impact of each item on the product and what we can or should be do in order to give the best response to the probable impact. The best way is to create a product requirements matrix with all the needed activities, new features, platform changes, etc. and then to prioritize this list.

Having done that, we need to figure out what is required in the development of each element in the matrix. We must get the rough effort estimation and / or the budget needed. Now we have the information needed in order to make decisions and to create a road map release plan, if possible for a 3 year period, but not less than 18 months.

Needless to mention that during all the process described here we need to drive internal collaboration and buy in by involving and getting the opinions of many other groups from within the organization for example marketing, R&D, sales, operations and so on.

This is a cyclic process, since we need to do it again at least once or twice a year and adjust the road map if needed.

The decision whether to let our customers be involved in the road map or more precisely to what extent they should be involved is not an easy one. See this article for some of our thoughts in this area. Generally we need to make the product ready for market, but at the same time, we need to be careful not to let the road map drift in the direction of one or two (big) customers, but, is not in line with the general market direction.

We should be very careful when externalize the road map document since it is has some legal status as a kind of contract and as such we need to enter all the needed legal and financial disclosures.

Hopefully this road map will lead us to Emerald City.

In subsequent blogs we will look at ways to share the roadmap internally and externally, getting internal buy in and some of the methods available to do competitive analysis and technology reviews.