Best practices in product development

January 25, 2016
28 min

This article gives you a collection of best practices for product developer teams. I've found these methods working really well at Google and other Silicon Valley companies, and they can be adopted easily.

We could describe these methods and processes as the infrastructure of product development: one can go a long way without such foundations in place, but it makes our lives much simpler.

Infrastructure makes far-away places accessible.

Executive summary

Manage goals

The development of a product can take many routes, and the success depends on the management deciding what tasks people shall work on, what are the goals that they need to achieve, and how they validate their work.

Having experienced all kinds of product and project management from waterfall through agile methods, with various tools from Excel to dedicated issue trackers and project planners, I've found that OKRs deliver the most benefit, while they require minimal effort.

Objectives and Key Results (OKRs)

OKR is a simple method that defines tasks through objectives and their measurable key results:

  • Objectives may be vague, high-level description of goals, something the person or organization wants to accomplish. It describes the general direction of the task in a compact sentence.

  • Key Results are specific, measurable details of an objective. They provide steps for measurements, concrete metrics that are easy to evaluate, calculate and compare. They can be fixed values, percentages, or a done / not-done checkboxes as well.

I'll provide a few examples; aim for similar length:

  • (A) Increase the quality of customer support.

    • (A/1) Increase the customer retention rate (during service calls) by 10% with a budget increase of maximum 5%. Service representatives will be allowed to decide claims under $50 without management approval.
    • (A/2) Decrease the median wait time on phone by 15%. First, we will educate the current staff on how to make the conversations shorter, and if that doesn't work out well, we'll hire more people.

  • (B) Implement a high-performance chart widget with advanced data exploration.

    • (B/1) The chart widget shall be loaded and responsible in 100ms for datasets under 1000 items. We shall explore deferred loading for some of the features.
    • (B/2) The chart widget shall display bar, line or pie charts per the user's choice.
    • (B/3) Support Venn diagrams (stretching goal).

  • (C) Research the technologies for our frontend development.

    • (C/1) Create a scorecard and evaluate the alternatives: plain JavaScript, Angular or React, and - as a stretching goal - jQuery.

OKRs typically originate from the top management, and cascade down. Each department, team and every single employee creates their own to get aligned with the organization above them. This connects the various groups and even remote teams in the company, making sure that they have a central reference point to turn to. Everything is open and accessible by everyone.

A company may have yearly OKRs, but most department and smaller teams shall use quarterly schedule to specify, and at the end of the period to evaluate theirs. Smaller teams could do a monthly status meeting where they can discuss their current state, and may raise blocking issues earlier.

The evaluation of OKRs should be simple, typically a percentage score, that can be aggregated over the total set of the goals. A few things to consider:

  • If your aggregate score is above 90%, it is likely that you have not been ambitious enough, with high risk of not using all of your potentials. Next time put more or more difficult goals into your OKRs.
  • If your aggregate score is below 50%, it is likely that you were too optimistic, or you have faced issues hard to predict. Next time you shall scale back and be more realistic.

Creating, tracking and evaluating OKRs can be as simple as putting them into a document (e.g. a shared Google doc). There are software tools that may help, but try to keep it as simple and small as you can.

Tracking OKRs is simpler than a calendar.

Eliminate bureaucracy

OKRs require much less effort to track and report the status than other methods. People are comfortable with the level of overhead it causes, and they understand the benefits. It is certainly a relief compared to certain project-tracking methods.

You shall follow that line of thought, and reduce, or even better: destroy everything that is bureaucratic. Question everything that requires a report, extra attention, approval or another person to look into. These things may divert the employee's focus from the core business goals.

If people have less things to worry about, they will work more on the stuff that moves the business forward.

Estimate honestly

Some managers love to set unreasonable goals for their team, so that they can constantly request them to work harder or longer. As a consequence, the deadlines are never met, the project is always behind schedule, and the morale is at the bottom. Usually these projects and teams don't become success stories.

OKR enables an honest conversation about how reasonable the goals and the related work are. It also provides a simple and easy-to-track feedback loop, that calibrates planning. In the end, it will enable the business to predict the future deliveries better, minimizing the related risks.

Introduce new features sparingly

It is easy to collect new requirements, features that may be nice to have. It is just one more of that little thing, let it be a field on a form or a button that does something when you push it. Most of the time it's easy to bolt these on the existing product, but it is extremely hard to make these new addition in a way that is consistent, discoverable and convenient to use.

A single feature requires a lot additional items.

The hardest part of product development is to cut the product back to the features that are really essential, and not introduce anything that makes it more confusing, complex or unfocused.

A product manager shall consider each change with its full scope, surroundings, and consequences. It's not unusual that they will say 'No' to most of the new requests, but saying no is not enough in itself. One shall have a clear idea when and on which circumstances could that feature be introduced in the future; outline the conditions, and keep it in the backlog. This kind of output is useful too, as it gives more depth to the product manager's work, and can be reused by others too.

Manage innovation

For a casual observer, new discoveries and breakthroughs may seem to be random events. We may attribute it to a genius mind, accidental luck, good timing, or the combination of those. Nevertheless, we can find enabler patterns, which increase our probability to succeed.

Depending on the budget, industry and people's willingness to experiment, one shall find suiting methods for their particular field and product.

Moonshots and 10X

The importance of the Apollo-program was not only the demonstrated ability to land on the Moon, but it also provided inspiration for entire generations. It was a hard problem to solve, and engineers, contractors, or even sourcing assistants were proud of their contribution to it.

Moonshot projects may be crazy, too big, or out of the business' scope, but the process of analyzing the problems and possible solutions can teach important lessons. It fosters discussions about 'How?' and 'What is missing to achieve that?', and presents a good reason to explore some of the unknowns.

Trying to solve hard and worthy problems will make your team proud of their struggle, it will encourage companionship, and keep the morale high. It is not imperative that you shall or will solve the big problem in a fortnight, especially if you need to make a living while working on it. You shall work with realistic near-term goals, but having a Moon around the corner always helps to keep long-term focus.

A big challenge inspires us.

One way to strike a good balance is to consider 10X improvements over the current designs. 10% improvement is almost always within reach, and one can work and deliver 10% in a year or two without much thinking. But making a change that is 10 times more effective than the current one forces us to rethink the design, how it works, and how it could work differently.

My favorite 10X examples are the spy and stealth planes made by Lockheed Martin's Skunk Works from the 60s until the 90s (and they probably keep doing new stuff):

  • The U-2 spy plan was designed to fly at ultra-high altitude, above the presumed reach of Soviet radar system. The range was well above the era's technical capabilities, and required to introduce special body construction, a new jet fuel, a very high resolution camera and other technical feats.

  • The SR-71 was designed to fly at the sustained speed of 3.2 Mach, faster than anything else, and it could keep doing it long enough to outspeed enemy missiles behind itself. It required special titanium alloy, new manufacturing procedures, a special navigation computer, and had the precursor of stealth technologies.

  • The F-117 was designed to leave a radar cross-section of a small bird, something that operators just don't give a damn about. It required automatic planning and attack systems, to keep it in stealth mode most of the time.

Each of these requirements provided a huge jump over the current standards of that era, allowing to rethink and redesign the airplanes.

10X tasks provide big leaps in the underlying technology.

Fortunately, you don't need to work for the defense industry to find such big challenges, one can find a 10X improvement in everyday software development too. Do you have a system that displays your data in 3 seconds? Why not aim for 300ms? As you start to explore and evaluate the options, you may find that you can improve it up to 550-600ms in a year, but if you would have aimed for only 2 seconds, you may have got 2.5 seconds as a result.

Enable 20% projects

Not every business domain, not every work assignment is as glorious as landing on the Moon. But not all is lost for those of us, who are assigned to work on a tedious tasks. Google hit the headlines that they encouraged employees to use the 20% of their time to work on products they thought would be beneficial for the company.

Over time, the concept of 20% got mocking and critique, but during my four years at Google, I've found it very rewarding. There are a few major benefits of allowing people to work on 20% projects:

  • Some people have genuinely new ideas, that need time to flush out, be explored and formulated. An early version may not got the liking of the managers, but given enough time, it may become an important part of the product line.

  • Sometimes they are fixing pain points that normal planning overlooked or didn't find important enough. It may introduce a productivity benefit for the entire team.

  • For others, it may be a good opportunity to get to know new people in the company, to talk, think and socialize over interesting problems. It is much better that they talk about solving parts of the problem over lunch, than to argue about politics or the soap opera from the previous day.

Giving 20% project time doesn't mean it is a free reign, or it is unattended. People do get lazy and may lose focus, therefore, make it part of the regular status updates. However, while implementing the normal tasks may receive some grilling over the details, talking about 20% time projects should get encouragement and inspire new ideas.

If you think somebody is heading towards a dead end, introduce a clear metric that can be used as a stop-measure to prevent waste of time.

Don't worry about people who may not be that innovative or lose focus. Because of the openness of the status updates, they would rather not do 20% and will work on their regular job, than to get a bad reputation in both of them.

Encourage internal pitches (demo days)

Another way to foster out-of-the-box thinking is to batch the 20% time in a week-long sprint. Make people form small teams, where they can collaborate on any tasks that they see fit for that week. They should spend the earlier weeks collecting and publishing ideas, so that they have a good selection of them to choose from.

At the end of the week, they shall do a short demo or a presentation of the stuff they have developed. Give out prizes for the forward-looking designs, and let small teams to continue working on the ones that you think may be beneficial for the business.

Demo days should be about creativity and fun.

Depending on the size of the organization, it may yield only a few new features, or it may create entire new business lines.

Organize competitions

A more focused way of channelling ideas is to organize competition around a specific topic, for example making some part of the system more reliable, faster, smaller, simpler...

While the previously mentioned methods rely on the imagination of the people, this requires preparation from the manager's side, as it needs clear, measurable and comparable metrics.

Give the teams enough time to explore and submit their suggestions, and provide a leaderboard to track the current status. Give prizes, and integrate the best solution into your product.

Stimulate the mind

Discoveries are often made at the overlap disciplines. An experience and insight from one domain is transferred to another, enabling new ideas to emerge. You can increase the probability of this by stimulating the people's mind with diverse thoughts.

At Google, there is a team that organizes talks from every aspect of life: researchers, engineers, managers, business and community leaders, authors, teachers, athletes, artists, musicians, NGOs and even politicians are invited to discuss their work, the issues they are facing and their current solutions. Employees are encouraged to attend these talks, and are free to offer their help (within their confidentiality agreements).

At one of those occasions, I remember having an outdoor meeting with a researcher from a local wildlife preserve, discussing how to engineer tracker devices for elephant seals. A fascinating problem, given that such device should operate for a long time (ideally 10+ years), in harsh conditions (these animals can dive a mile / 1.6km deep in the ocean), and should survive competing males crushing on it.

It is not feasible for every company to organize talks at similar scale, but it is always within reach to arrange and participate regular local events and meetups. At a minimum, you shall have a corporate mailing list or an internal social network where people are encouraged to share such stories and talks.

Manage knowledge

During product development, new information gets uncovered everywhere: a lesson about the business domain, about our tools and technologies, how our customers are trying to use the product, etc. We need to learn from these, but it's hard to do with lots of moving parts in a complex environment.

Knowledge management is a process around this learning. While we are working, we need to capture and organize the context in a predictable way. Later on, we shall be able to recall and study the context again, without any guidance from the person who did the work. This allows the organization to make use of these lessons, and achieve much more than any single member of it could have done.

Version control everything

Software engineers use revision control systems for ages, but analysts, designers or managers tend to stick with the old-fashioned 'put everything in a single directory and append a version number to it'. As a consequence, their work is often out of sync, contains obsolete information, and requires a periodic and wasteful review to get it aligned with the reality of others.

The best way to prevent this is to put everything under the same process, under the same version control system. Let it be a design document, a business requirement, a detailed description of a bug, source code, or a drawing. Store every digitizable part of the product in the same version control system.

When you are investigating the reasons behind a specific item, you shall be able to recall the situation in its full context: you will know about the priorities, bugs, ongoing discussions at that time.

Review every change

Make peers review each other's work, ideally before submitting them into the version control system. The reviewer can go through the details, ask questions, give more insight, or even call out for reconsideration and alternatives. They may also ask for the update of bug entries or the documentation.

An open and well-designed review system not only helps to improve the quality (e.g. catches bugs earlier, makes it more readable and understandable), but also spreads the knowledge of the internals between the team members. If your go-to person leaves for a 3-weeks vacation, you will be confident that you have a few solid backups.

Process issues in batches

While some teams have a dedicated QA staff to check the quality of the product, it is always worth to make the developers do some further testing themselves. Create a regular weekly meeting in the afternoon, get some snacks, drinks (light beer), and create a fun event (bugfest) around it.

A good bugfest checks for regressions, and also explores the product in non-trivial ways. As somebody discovers an issue, by showing it to the others, they can quickly figure out who is the best person to deal with it. The recording of the bug and assessing the owner can be done at this time. The team shall also discuss the importance and priorities of the issues: it is a free-form, low-pressure way of distributing the required work.

If you can't keep up fixing the bugs while developing the product, it may be a good idea to carve out a week or two for a hackathon. During that time, it must be forbidden to work on any new stuff, everybody should be working on the bugs.

Depending on the team's size, you can make it a contest between smaller groups or individuals, and give out prizes for the best ones (either by bug count, or by bug complexity).

Give prizes to the best bug fixers.

Deprecate features, bugs and documents

While recording the context of the product makes sense, there are features, blueprints, bug reports and other documents, that become obsolete. As the market or the product changes, the attentions shifts from them, and it just doesn't make any sense to keep them around. People will have them in their mind (or they pop up in a search), and they take precious focus away from more important things.

It can be another fixit, maybe a half-day long, where everybody is tasked to deprecate whatever they can find. Similarly to the bugfests, this shall be a community event, with foods, drinks and lots of conversation about the stuff the team finds.

If you are using version control system for everything, it means that you won't lose these items forever: in case you really need them, you may get it from the revision history.

Use shared places to inform

Some information may be easily skipped when sent out by e-mail, because it is not urgent, and there may be an important work that needs to get dealt with. Best practices, how-to start with X guides, smart tricks and tips, community events and other small infobits can fall into this category.

Learning-on-the-loo is a concept that spreads these ideas in shared spaces: in the kitchen or in the restroom. People may spend only a moment or two to skim the subject, but the repeated exposure does get the message through.

You can start with 5-10 one-pager topic you can print and distribute in small batches. Select 2 or 3 to start with, and change some of it each week. Put them over the kitchen counter, over the pissoir, inside the bathroom stall. Encourage people to write their own article and add them to the circulation.

Manage people

Ideas and solutions do not come from the company, from the tools or from the process, they come from the people. To achieve their full potential, the management shall do everything that unblocks their work.

Hire people smarter than you

People like to work with teammates that are smart, pro-active and solve problems. This preference goes both ways, and except for a small minority that is insecure in their standing, most pro-active person prefer to work with other pro-active colleagues.

There are many other reasons for hiring and working with smart people:

  • One smart guy may dominate the team with ego, but with many intelligent person around, ego tends to be left outside of the room.
  • Surrounding yourself with great talents, the assumptions and solutions will be questioned, while the deliverable will be improved to levels that none of the individual members have ever imagined.
  • Smart people understand the strong points of each other, and delegate the task to the most capable person to solve it.
  • Knowledgeable people will be able to have the time and confidence to explain complex issues.
  • Pro-active people won't hide or dodge problems, they will try to analyze and solve them.
  • Science-minded people challenge the authority, conventional wisdom or statements without proper backing. They will not rest until somebody provides sufficient proof.

Working with smart people changes the work dynamics: instead of looking over their shoulders in every minute, the managers can and should trust their decisions, and verify them infrequently. Giving them authority and responsibility is a must.

For the same reasons, smart people are in great demand, and it drives their compensation up. It is always a bad idea to cap a person's salary at the level of their boss, as they provide different values to the company. When the specialists provide the most value, they should be treated as such.

Interestingly, it was the previously mentioned Skunk Works' director, Kelly Johnson, who in the 1950s made it a rule to compensate engineers on their merit, and not on their number of direct reports:

Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised. Kelly Johnson's 14 Rules, #14

If an engineer or other specialist is not comfortable to take a role in management, by no means force them to do it. In Silicon Valley, it is not uncommon that a senior engineer is working without any people to manage, yet, it does not affect their compensation, they can make as much or even more than the people managers or area leads around them.

New member onboarding

Pay special attention how new team members can learn about their work and what is expected from them. For a new hire, becoming productive may take months, especially if you do not have a good onboarding process in place. They will bug their teammates or mentor with questions that they could have learnt from a single document.

It is important that you keep the onboarding document up-to-date. Storing it in the same version control system helps, because the reviewers can always ask their peer to update it too. Otherwise, you shall schedule a periodic review of the document.

Help new team members to feel secure.

Keep people moving forward

While it is important to get the new members up-to-speed in a short time, it is even more crucial to keep the solid and performing team members with the company. Invest in their tutoring, personal development and growth. Treat them well, and let them know that they are needed.

Besides the training, it is a good practice to periodically adjust their compensation to their fair market value. This is not necessarily based on the original salary they have negotiated, rather it is a combination of what they could get with their current knowledge, and what it would cost you (including lost opportunities) to get a new team member up to the speed of the current colleague.

And of course, the classical CEO-CFO conversation applies:

"What if we train our workers and they leave?"

"What if we don't train them, and they stay?"

Rotate tasks

In most cases, there are tasks that may be tedious, for example providing on-call support, monitoring the production line, being a build-cop or an issue organizer etc. Usually the senior staff takes ownership and responsibility in these tasks, but it may wear them down (too much, or too boring, or out of the scope of their ordinary work).

Instead of delegating such tasks to a selected person every time, let's rotate it among the team members. In some cases it is advisable to make it happen with a second layer of rotation, where a mentor can oversee the work and jump in when required.

Task rotation is great to decrease the burden on the individuals, while it also creates a shared mission among the peers. As they all become part of it, responsible for it, they will have a common interest in its success, and they will double their effort to prevent issues from happening. It is also great introduction to parts of the system they are less familiar with.

Task rotation helps to keep overall morale high.

Fine-tune work culture

Performance reviews give insight about a single person's output and how much value they provide in the specific role. But that metric is blind to the fact that people interact and communicate with each other, sometimes helping out, sometimes making harder the others' work.

It is important to give people a toolset and actionable steps to improve their habits at work, the unwritten culture how they handle their stuff.

Encourage positive feedback among peers, let them give credit easily when credit is due. It can be a small monetary award that they can grant among themselves. You may give spot bonuses for specific actions, which could be examples that others should follow. Make a small buzz around it.

At the same time, try to detect and dismantle toxic behavior, like jerks having their ways without any pushback. They will suck out the positive energy of the team, and people will rather leave than put up with it.

In the past few months I've been visiting events and companies that have close ties to the Hungarian Association for Innovation. I was discussing my experiences in Silicon Valley, and I ended up promising a guide about best practices I've seen at Google and similar companies. This is it.

I do hope that teams, managers and founders find this article useful and inspiring. Please send me your feedback.

software engineer, business advisor

Advocates for the maker-movement, self-directed learning and agile methods. His regular topics include: machine intelligence, data and risk analysis, distributed systems and knowledge management.

Question? Comment?
Contact us!