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.

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.

Spotting Disruptive Technology - Timing is Everything!

In the first post in this mini series on Disruptive Technology I discussed why we need to expect the unexpected - in a nutshell most of us spend our working days involved in our daily routine trying to plan develop and market our product. Meanwhile, whilst we aren't looking or dreaming in other directions there are groups of people who have dedicated themselves to doing something completely different and destroying our product and our market. It's nothing personal - its just (to paraphrase) - all is fair in love, war and technology development. Its been happening for a long time - think of the canal owners who suddenly had a new competitor with a new bigger faster technology called the railway. Or carriage makers just before Mercedes, Benz and friends came along.

In this second post we will discuss the timing impact and various key questions that are really just questions of timing and product timing decisions.

So we have made firm resolutions and have spotted some disruptive technology lurking somewhere away on the horizon - what's next?

Unfortunately, spotting these potential disruptions is only the tip of the iceberg, it is all to easy to be drawn in by the hype and buzz around these new areas. Firstly, curiosity is a strong human trait (and it is generally well developed in Product Team Members), the buzz can be more exciting than our regular work and in big organisations it can seem to be a way to stand out from the crowd (guru).

On the other hand, it seems that everybody is doing this. Remember, there are people out there who earn their salary creating this impression. Without being too cynical, the technology hype pays their bills.

For those of us who played team sports as kids remember how everybody used to chase the ball - didn't matter if you were defence or attack you ran after the ball. Later on we developed more discipline and strategy and stopped chasing the ball and started to play the game. That is one of the challenges of disruptive technology - to figure out when to chase and how to play the game.

So in analysing Disruptive Technology we must then exercise our judgement on the probability that the technologies will mature, that they will impact our area, and finally the hardest question of all - when? What is the relevant time frame?

Getting these factors wrong can ruin a perfectly good business or product strategy no less than ignoring or not spotting the technology. By way of example in the Telecom space around 2005 everybody was buzzing about IMS and how it was going to change the Telecom industry as we knew it. There were almost daily announcements of new products, initiatives and commitments. It seemed that overnight all our calls would be IMS based.

Looking back the objectives of were valid, the overall impact of IMS and IMS like technologies has been profound and are on going - but from a telecom's industry perspective "the reports of my death have been greatly exaggerated" (Mark Twain). In summation without getting into a theological argument (IMS believers vs. IMS non believers) by 2011 we can say that IMS is not yet main stream and whilst it has impacted many businesses it has not (yet) fulfilled its hype of 2005.

Clearly, companies that assumed that IMS was the next best and greatest thing made the wrong call. Whether this was to develop new technology products based on IMS or to build consumer and business services over IMS they are probably somewhat disappointed. Equally so you could have made the decision to stop investing in current development (to favour IMS) and missed out on a lot of opportunities in the last 5 years or so.

The point of this post is not to analyse IMS in depth, but to use it as an example (from our own industry) of the dangers of incorrectly analysing the impact and the timing of the impact on a product space. Many companies made the wrong judgement call.

Looking back the single most important error was probably the lack of business case to justify such a large risk and technology change. (A reminder to always use business fundamentals.) There was huge hype and like the example of team sports earlier, everybody was chasing the IMS ball. There were only a few brave solitary voices in the wilderness calling out with a different message.

Overall IMS is a good example of a disruptive technology that many spotted, but very few managed to answer the key questions of the probability that the technology would mature, its impact on their industry and most critically on when it would impact. Ultimately, all these questions become a question of timing - when will it happen?

The product teams involved had to set their product requirements, make their product decisions and position their product based on their assumptions about the impact of this disruptive technology. Many errors were made.

Clearly it is key to our product and business strategy that we actively seek and successfully spot disruptive technologies. However, we also need to be able to stand back from the hype and think strategically and coldly analyse the likely impact and timing of the new technology.

The final posts of this series will discuss some practical ideas for systematically discovering and analysing new technologies.

WAC - Innovation & Standardisation

As telecom guys, we can’t let last week’s Mobile World Congress go by without a mention. One of the announcements was about the WAC (Wholesale Applications Community) standard. The WAC initiative was founded a year ago, has published v2.0 of the standard this week and plans v3.0 later in the year. A few telecom operators and suppliers have made some supportive announcements.

The basic idea of WAC is to allow developers a device agnostic way to bring their products to market and it will also improve operator involvement with application stores by allowing the operators to offer added value and services through their network. It is the latest in a series of initiatives to try to standardize this area of the telecom market.

Significantly Apple and Google are not members of WAC and are enjoying significant commercial success with their application stores. (In January Apple announced the 10 billionth app download.) They both choose to innovate aggressively, to create their own solution and to shun the standard approach.

The purpose of this blog is not to debate the merits of WAC, or its chance of success, but rather to consider the correct balance between standardization and innovation from the perspective of Product Management & Marketing.

Conventional wisdom (since the days of Henry Ford) has been that standardization rules. It simplifies the process, drives down costs and is at the core of mass production. WAC has the same objectives in mind – “WAC is …..dedicated to establishing a simple route to market for developers to expose their new applications to a customer base of over 3 billion customers.” It has been a brave PMM that has chosen non standard solutions – they increase cost, reduce the likelihood of success and are generally guaranteed to cause project delay.

However, Apple and Google have gone their own ways; and built their own solutions and created de-facto standards around their own eco-systems. Their strategy is that standardization should not be allowed to obstruct innovation. (There are many other technology examples in the past that followed the same basic strategy.)

However, also in the Telecom news was the agreement between Nokia and Microsoft. Behind the headline is the recognition that these two mega companies each with a strong tradition and proved track record of innovation have failed to deliver individually with Symbian (Nokia), MeeGo (Nokia & Intel) and Windows Phone 7 (MS). So clearly innovation even when driven by market leaders is no guarantee of success.

Often the process of standardization reduces innovation to the lowest common denominator to reach broad consensus and it can be driven by strong partisan commercial interests. In almost all cases it slows down the process – WAC is a good example. Compare the few early commitments with the number of devices and solutions in the Droid and Apple app stores.

Of course most PMM do not have the luxury of being able to create eco-systems on the scale of the app stores. However, we do need to balance standardization and innovation. Even today it is probably a wiser move to innovate in the context of app stores and not to rely on the WAC standard.

In many ways it is harder for the regular PMM; our product decisions are complex. We have to balance our need to differentiate with the need to be accepted via standardization. Our products are often expected to differentiate. We must also make some tough judgment calls on which are the correct standards and if it they are really appropriate for our product. If we are building a bleeding edge product we will often need to decide how we build a product that can be launched today yet is flexible to rapid change if a standard develops in a different direction.

Standardization is needed and should be supported, yet we need to remember when and how to innovate. Clever well executed innovation can be much faster to market and a strong differentiator and there is always the (remote) chance of creating a de facto standard!

When we manage our products we need to carefully evaluate what is our true ability to innovate and to generate product leadership and differentiation and when should we rely on standards and standardization. This is not a purely technical or tactical question. It is a strong commercial and strategic decision; just because a standard exists it does not mean that it will be commercially successful, nor that it is the correct product positioning for our product. The Telecom world has many examples of the standard that never caught on; Betamax is another example of the standard that didn’t bring commercial success.

However, to ignore an easy standard solution will ensure that we invest scarce resources in re-inventing the wheel rather than in creating the product we want in the time scale we need.

The balance between innovation and standardization is very difficult to achieve. Standards can simplify our product yet take time to evolve and are frequently not the best solution. On the other hand, wild innovation can produce an isolated, weak, expensive and late solution. However, without innovation it is very hard to differentiate at the product level. Finding the correct balance between innovation and standardization is The Art of Product Management & Marketing.

Does the Perfect Product exist?

So we all know that one of the hardest things about being a Product Manager is trying to get the product to the market - preferably with most of the required features and in the same decade as the target launch date.

Product timing is critical - often it is better to be in the market with a less than perfect product, getting customers involved and committed than still be in the labs working and missing the opportunity - although a poor offering can do incalculable damage to our product and our brand.

This inevitably forces us to make tough product decisions and compromises on what is in and what is out. We would all like the perfect product, but, in practice we try and define what is good enough. We need to review the product requirements and categorise (in reality recategorise) them into features that are key to the functionality, for example product differentiation and leadership, competitive positioning, key customer commitments (but see this post on balancing customer influence on a release) and usability. There will be many other features, that make sense for the overall product offering, but will not gain customers nor will they loose customers and so sometimes they will just have to wait for the next release.

These calls can be tough and it can take a brave PM to stare down the boss and the market. When Apple introduced the iPhone it was revolutionary (touch screen etc), but at the time it missed some of the key features of a phone that traditional phones already supported (network technology and speed.) Some poor PM in Apple had to make the call and say those features could wait. In this case it worked.

Sometimes, however, the choice is less successful and worse some minor features get delayed from release to release without a solution. So following on from my analysis of Nike getting some marketing issues wrong - here are some thoughts about a place were Google gets it wrong.

Briefly, when you build a website, two of the key stages in launching it are to submit the site to the major search engines together with its sitemap.

Now when we built this blog we built it on a Google platform, and naturally assumed that submission to Google would be automatic. Not so - a few weeks on and we realise that we seemingly need to submit and that the submission is from a different set of Google tools and not the blog control panel. Even more frustrating, building the site map probably isn't automatic and doesn't always work the way they say. Or maybe it is automatic - depends who you believe - the Google support guy on one of the forums or the official instructions. Worst of all - this saga seems to have a history judging by the support forums and QA pages.

So given that these tools are for the general public - the user experience could have been so much smoother. Maybe there is a very good reason why submission isn't automatic - but it is hard to see why this couldn't have been properly explained and a couple of items included in the blog set up wizard. True in this case they didn't loose me as a customer, but they almost did see me checkout a different blogging platform.

To wrap it up - we need to compromise on our dreams for our products, failure to do so can ruin our chances to get market share, but, we need to make sure that we don't compromise too much. We need to listen to our customers and fix the things that we missed or omitted the first time round, failure to do will also ruin our market share in the longer term.

The Importance of Documentation

As PM&M we spend a huge part of our working day communicating both internally and externally. Despite this, we often get far into a product process and discover that somehow we don't have documentation or that we have very poor documentation. It may not, therefore, come as a complete surprise that we have a poor product definition and a weak customer engagement.

Sure, our creative skills and leadership mission don't leave much time for hacking away producing long word documents, but, as we will discuss in this post good functional documentation is an essential part of our mission and the craft, that can help or hinder the overall business success.

We welcome a guest blogger - Larry Lester - A Sales & Marketing Documentation Guru to discuss

There’s a host of reasons why small, emerging companies (aka start ups) should take documentation seriously. The problem is that most of those that I have worked with – don’t.

First and foremost they should take it seriously for all the reasons that larger companies take it seriously – it is a way of keeping your marketing, development, operations, and sales efforts – and the also the customer – in alignment.

However, for a start up the lack of good technical and marketing documentation – with the emphasis on good, or not having something basic at least – makes survival more perilous than usual. My phone usually starts ringing when these guys are about to crash land. If they have had the good fortune to make a sale, the customer is being nasty and delaying a milestone payment because a full set of technical documentation was supposed to be delivered and has not even been written. Or, if they have only got their foot in the door, discussions are about to collapse as the only marketing material they have to give to potential customers are a few pages of incomprehensible gibberish and a dreadful PowerPoint presentation! “We thought we could pull it off”.

The situation is, in fact, more serious than that. A company that does not maintain product requirement documentation is openly toying with suicide. There are two aspects to this assertion.

1. Poorly documented development is bound to result in a bug-ridden product. If you don’t write about it (requirements) then you don’t talk about it, and if you don’t talk about it, you brush aside the problems. Lack of a standard process and workflow causes product decisions to be made in an ad hoc way. At best, it is inefficient. At worst, it will kill your efforts to make a sale.
2. A good product requirement or a spec can serve as the basis for installation, operation and maintenance documentation. The saving in time, energy and money can be substantial. Somewhere down the road, you will need a technical writer, whether you like it or not. The more solid information you have to provide, the easier your lives will be.

The bottom line: give both technical and marketing documentation the same priority you give to development and sales. All of these processes are fully entwined - together the product should succeed; without any one of them it will be a struggle and potentially a product failure.

Cloud Computing - should it / will it impact our product?

I recently attended a conference on cloud computing, held by The Virtual Computing Environment Coalition (VCE), a coalition of three of the leading vendors in the industry: EMC², Cisco and Vmware. Virtualization and cloud computing are two of the newer technological trends and gaining momentum every day. Gartner EXP Worldwide Survey of Nearly 1,600 CIOs indicates that in 2010 the first technological priority of the CIOs is virtualization and second is cloud computing. This is a major change in the IT industry; in the same survey in Jan 2009 neither of these were in the top ten technologies.

New technologies always represent a challenge to the Product Mangers. Should we invest and adapt the technology or is it only a “buzz” that will disappear? In some cases it introduces a disruptive force to the industry which actually changes the rules of the game, creates an opportunity for new players and might be a threat to the existing players in the market. So, the stakes are high, misjudgment of the affect of the new technology might cause a large impact on our business. We will discuss the importance of and ways to track technological trends in a future post.

In the case of cloud computing the potential affect might be more than only on the product. It might change the way we do business. Should the business be “product centric” or should it change to a xAAS model?

As we discussed in the post “the Craft of PM&M”, one of the main challenges is to make a decision in a world of uncertainty. The impact of Cloud Computing will be different between industries and between domains within a specific industry. There is no one answer that fits all. Each PM in his/her own domain should consider the wide view of the industry and take into account the users and usage habits, the competitors, possible new competition due to the change, the customers (if the users and customers are different), and the maturity of the technology related to the specific industry. Our task is to correctly position the product.

The decision to be made is not between ignoring the change and fully embracing it. There are several alternatives to implement or approach a change. We need to determine the correct product requirements in the light of the possible changes.

We can choose not to do anything and wait. The simplest approach, before making substantial investments, is to change the “marketing language” that is used to describe the offering and start using the newer, trendier, terms when describing the product and the offering. The next step is to create a demo which is more convincing than the marketing pitch. Moving up in the investment and the complexity, we can build a “Proof-of-Concept” which is not only a demo but still not a product that can be delivered to customers. Finally, if there is a decision to adapt the technology, only then we should implement it in the product.

Whether we choose to ignore the change for now, or choose any of the other alternatives we must decide on parameters or events that we should track. These parameters and events should signal us if a decision should be changed. They should indicate changes in the market that point to either the direction of adaptation of the technology by the market or that the market abandon this trend. Any change that indicates a deeper commitment and implementation in the market should cause us to reconsider our strategy and move to the next level of investments in our offering.

Cloud Computing is an interesting topic in its own right and it serves as a good case study for the wider discussion of technological change and product positioning. Constantly, there are technological trends to follow, but not all trends are relevant to all domains and products. However, it is crucial for a Product Manager to keep track and to be informed so that those trends that are relevant will not be overlooked. Missing on a relevant market trend might not have an immediate impact but can prove to be critical in the mid and long terms. It is also important to make the correct call on the required response.

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.