One of the most common situations today is where the product manager is in one location, and the engineering team is somewhere else. I don’t only mean outsourcing to India either – the remote development team might be a consequence of an acquisition or merger, or possibly your organization is large enough where the developers are centrally located in a facility somewhere you aren’t.

When the developers are not sitting right next to you, then all of the normal challenges of communication and execution are magnified, often to the point where many teams get extremely frustrated with remote development, and some challenge the benefits of the perceived cost savings.

I have written earlier about some of the problems that come with outsourcing for the wrong reasons, but whatever the cause, if you find yourself with a remote development team, there are three critical things you can do to dramatically improve your odds of success:

1) The further away the team is from you, and the more the communication challenges of language, culture and time zones, the more pressure there is to ensure that you have done a very good job on the product spec. The nightmare project is where the product manager isn’t sure what he wants built (or keeps changing his mind) and the remote engineering team is thrashing. It’s like being on the wrong end of a whip. In the last article I wrote about the importance of a high-fidelity prototype as the basis of the product spec. I won’t repeat all the reasons for that here, but suffice it to say that if your team is remote, you absolutely positively want to make sure you use the high-fidelity prototype as your main communication mechanism. Both for communicating the actual spec, and for communicating changes. Written documents are hard enough to get people to read, but if it’s written in a language that isn’t native, and if you don’t have the author in the cube down the hall to interpret it to you, you’re just asking for big trouble.

2) When a development team is local, if there are resource conflicts (for example, two different managers give conflicting instructions) then this is typically caught quickly and resolved. With remote teams, you end up getting lots of unpleasant surprises, and literally months can pass before the disconnects are identified. This is usually because the remote developers are forced to make assumptions about who wanted what and how to interpret the various instructions, and the assumptions are rarely correct. It is critical to have someone local manage all coordination with the remote team. This doesn’t mean that all communication should be funneled through this person, but there should be no question as to who the engineering team is accountable to. Sometimes this is a project manager (aka program manager) and sometimes this is a director or VP of engineering that is based locally (near the product manager).

3) There are so many good communication mechanisms now. In addition to e-mail and instant messaging, video conferencing is much better, and VoIP has brought the costs way down for international calls. That said, there still is no substitute for establishing the personal relationships. At least once a quarter, the product manager should get out to the engineering team, meet with the key architects and managers, and spend some quality face time. This will improve all the other forms of communication. Another great technique here is to have an exchange program where key developers come stay with you for a while, and you go there for a while.

If you have a talented remote team, and if you are managing the relationship as I’ve described, you can actually come to enjoy this arrangement. Especially with engineers based in India, the time difference can make it such that every morning when you come in you see progress waiting for you, and you can spend your day (and their night) reviewing and testing and providing feedback. The result can actually be extremely fast cycle times.

Note that you can also have your prototyping resources remote as well, but you’ll have to work a little harder on the communication and be more flexible on your hours, because of the very quick cycle times (several iterations a day).

Yet another solution to the problems of dealing with a remote development team involves locating the entire product team together in the remote location. I see this trend just starting, but I think it will be profound. That said, you don’t have have to worry about this just yet. It has taken 10 years to develop the engineering and QA capabilities in these remote locations, and it’ll likely take another 10 before these locations have skilled product managers and designers as well. But that’s a topic for a future article.

Email to a friend

Sign up for the free newsletter here.

I think the product spec is long overdue for a renovation. Some would argue that Agile methods accomplish this by doing away with the spec altogether. I’ve written about some of the issues and limitations of Agile methods elsewhere, but in many respects I think they were on the right track.

But before we get ahead of ourselves, let’s start by discussing the problem to be solved.

There is of course tremendous range among product specs, starting with what we call them (Product Requirements/PRD’s, Market Requirements/MRD’s, Business Requirements/BRD’s, Functional Specs/FSD, and more). The topics covered can vary greatly (these different documents were not intended to serve the same purposes, but over time they have merged and morphed and lost many of their original distinctions), the level of detail, and of course the quality of the spec itself. Even the form varies greatly – many use MS Word docs, but some use spreadsheets, some post the spec on a Wiki site, and others use one of the commercial requirements management tools.

I have seen a few truly good product specs, but much more often than not, most specs take too long to write, they are seldom read, they don’t provide the necessary detail, address the difficult questions, or contain the critical information they need to, and most importantly, it is all too easy for the mere existence of the spec to serve as a false indicator to management and the product team that everything is proceeding just fine.

If you agree with me that the central responsibility of the product manager is to make sure that you deliver to the engineering team a product spec that describes a product that will be successful, then we have to acknowledge the weaknesses in the typical spec process and take a hard look at how products are defined.

Here are what I consider the requirements for a good and useful product spec:

- the spec must describe the full user experience - not just the product requirements but also the user interaction and visual design. By now hopefully everyone recognizes how closely intertwined the requirements are with the design.

- the spec must accurately represent the behavior of the software - and we need to acknowledge that words and pretty pictures are just too limited in their ability to describe this behavior.

- there are several critical consumers of the spec - engineering, QA, customer service, marketing, site operations, sales; as such, the spec needs to communicate the behavior of the product in a way that all of these groups get what they need.

- the spec will change - the rate of change should slow down dramatically once engineering gets started, but there will be decisions and issues that arise, and the spec should change to reflect the very latest decisions.

- there are a number of artifacts in the creation of a spec, such as lists of prioritized requirements, wireframes, and mock-ups, but there needs to be a single master representation of the spec, to minimize confusion, ambiguity and versionitis.

In my mind, there’s only one form of spec that can deliver on these requirements, and that is the high-fidelity prototype.

The term “high-fidelity” refers to the fact that this should be a realistic representation of the proposed user experience. Except for the most trivial of user interfaces, I am not a fan of so-called “paper prototypes.” With the tools available today, it is now so quick, easy and inexpensive to create a high-fidelity prototype for most products that there is no reason not to do so. This is still a prototype, so it’s fine to fake (simulate) the back end processing and data, so long as the user experience is plausible.

Over the past few years, my own thinking has evolved here from just prototyping a few critical components of the user experience, to now I advocate prototyping virtually everything – all pages/screens, and all the major use cases. There will still be some error conditions and corner cases that don’t pay to prototype, but the benefits of having a high-fidelity representation of the product that the full product team can interact with to understand the product to be built are so great that they dwarf the incremental costs.

It is true that you will still need to supplement the prototype, as there are aspects of the proposed product’s behavior that are not easily represented in a prototype, such as the release requirements (e.g. reliability, performance, scalability) or platform delivery requirements (such as installation requirements, or the list of browser versions to be supported). Also useful as a supplement are use cases, describing the most important flows through the product.

There is still the question of how to best represent this supplementary material. What I really want is to annotate the prototype, but until that technology is readily available, I prefer using a Wiki or other form of Intranet site. The biggest reason is that everyone on the product team knows where to find the latest answers at any time, rather than having various random versions of documents floating around. It is also easy to post Q&A’s, set up automatic e-mail notifications whenever the spec is updated, and track the history of decisions.

But the majority of the product spec should be the high-fidelity prototype, representing the functional requirements, the information architecture, the interaction design, and the visual design of the user experience.

In addition to meeting the requirements described above, the most important benefit in my view is that unlike a paper document, a high-fidelity prototype can be tested. You can put it in front of actual target users and ensure that they can figure out how to use your product (usability), and also determine if they care to use your product (desirability). You don’t actually have a spec worth handing over to engineering until your prototype passes these two tests. Doing this form of testing while you are in QA or Beta is far too late in the process.

I can promise you that if you give this a try, and create a high-fidelity prototype of the proposed functionality and user experience, then your product team will absolutely love this. Engineers are the immediate winners as they finally get a spec that effectively and unambiguously describes the product they need to build, and that they can refer to at any time when they’re confused about how something is supposed to behave. The job of QA is similarly easier as they now know what should happen when they test the actual product. Marketing, sales, and customer support will love being able to learn the product much earlier in the cycle. You’ll also find that your execs will love it too as they can describe what you’re doing (and demo the prototype) to investors, board members, and partners much more effectively than any PowerPoint deck can do.

But wait, there’s more.

The biggest surprise for most teams is that creating a spec this way will typically significantly reduce time to market. Yep. I realize this may sound counter-intuitive, but to understand why the total time to market is faster, you have to look a little deeper at what almost always happens in a software project. Because the typical spec is so poor (incomplete, ambiguous, and especially untested), and so few of the hard questions and critical details are actually addressed and resolved, it is during the engineering phase that the team is forced to tackle these issues, and either there is tremendous churn (the specs keep changing resulting in delays and frustration in engineering) or the engineers just make assumptions as best they can, and the product that ships is a mess and one or more update releases are required before you actually get something useful to your customers. In either case, the time to market is longer than it should be.

So I truly hope on your next product you’ll try this out. Rather than spend weeks working on a 50-page Word document that few will read and is impossible to test, work with your designer to create a prototype of the product you are proposing. Then show that prototype to target users, as well as your product team. You’ll end up iterating several times (better now than after engineering spends months building a bad product!), but when you get the recipe right, use that prototype as the basis for the spec you deliver to engineering and see what happens.

Email to a friend

Sign up for the free newsletter here.