The Architect Role

The job of the product manager is first and foremost to discover a product that is valuable, usable and feasible. You’re wasting the rest of your team’s time, and your company’s money, if you can’t do this. But this doesn’t mean that you have to discover this product yourself.

There are, in general, two other key roles besides yours. In other articles I have written about the critical role that a user experience designer (aka interaction designer) plays. In this article, I’d like to talk more about how and why you need to include the engineering organization in this discovery process.

First a terminology note. When I refer to “architect” in this article, I am referring to an engineering or systems architect. I’m not referring to an information architect (which is similar to an interaction designer and is part of the user experience team). Also, I use engineer and developer interchangeably.

There are actually two topics when discussing the architect role. The first is to discuss why and how to have architects participate in the discovery process. The second is to elaborate on this relatively new role within product development that has several benefits to the product organization.

Participating in Product Discovery

One of the most common mistakes that product managers make is to not include engineering early enough to make a difference. By the time engineering is often brought in, you are so far down a path that time is running out and there’s little that can be done. Sometimes this happens because the product manager believes it’s his job to define the product, and it’s engineering’s job to build it. Sometimes this happens because engineering is so busy building that they can’t free up any resources to participate earlier.

There are really two main reasons you need strong representation and active participation by the engineering organization during the product discovery process:

– First, the engineers and architects know best what is possible. They can help identify new solutions to user’s problems. They can contribute ideas, evaluate ideas, and improve on ideas. They are an absolutely essential ingredient to the product discovery process.

– Second, the engineers and architects can evaluate the cost and complexity of the different ideas and features. They can review prototypes, and help flesh out what is involved with each idea. It is essential that these time and cost estimates are provided early, during the discovery process, as this is key information for the product manager to decide whether or not a feature or capability is worth including in the resulting product definition.

The idea is to avoid the common problem where the product manager comes up with a great product, and then hands it off to engineering where they estimate the cost, and of course it turns out to be far too long to build, so the horse trading begins when it is too late to come up with good alternatives and test them with users; and more generally the problem of the product manager coming up with great ideas that are simply not feasible.

In terms of the engineering time required for this participation during product discovery, I typically tell engineering and architects that they need to plan for a few hours a week to review the latest ideas and prototypes and provide the necessary feedback. As product ideas progress, they’ll be asked to give more than just preliminary advice on cost and scoping, and at that point they’ll need to dig in more and provide estimates that the team can count on as they make the critical trade-offs.

The Architect Role in Product Development

As products and teams get larger, especially for large consumer internet sites or consumer electronics devices, the product development organization needs people that have a holistic view of the complete product. These people know not just one or two areas, but they are responsible for knowing, at least at a high level, how the whole product works including architecture, site operations considerations (including scale, performance, and provisioning) and topics such as test automation and release management. Increasingly I am seeing companies establish a centralized architecture team to develop these people, and I think this is an important trend, for several reasons:

– The architecture of large systems needs constant attention to ensure the system can continue to meet the needs of the business. This includes worrying about site availability, scalability, performance, maintainability and internationalization, as a few examples. The architecture team is always looking for bottlenecks and inefficiencies in the system, and they typically provide prioritization, guidance and assistance on the different areas needing attention.

– The architecture organization is an additional contributor to the overall Portfolio Roadmap. They are the owner of Technology Sponsored Initiatives, and often will debate with other parts of the business for precious engineering resources. The architecture and systems engineering activities need to be prioritized against other business initiatives, as it’s not always sufficient to use the small, dedicated group of system engineers and architects to do everything that must be done.

– It is important that your top engineers not feel that they have to move into management to progress in their career financially or professionally. The dual track serves this need well, and the architects are typically the top of the engineering ladder as an architect job is valued by the organization at all levels.

– The truth is that most product engineering teams today don’t maintain internal system documentation. They may have something written down but it’s probably old and nobody trusts that it’s accurate. So when new engineers start, they generally learn by talking to other engineers. The architects represent the institutional knowledge (living documentation) of the system, and they are responsible for helping new engineers learn the architecture and code base.

– One common and effective technique to ensure new work is compatible with the overall architecture is for the architects to attend all of the code and design reviews. This also helps the architects stay current, but the primary benefit is to detect and prevent problems in the code and architecture.

– The architects also are resources to help evaluate 3rd party integrations and participate in M&A; due diligence.

If you organization is small, your architect will likely just be one of the senior developers. But as your organization grows, a designated architecture team can make a big difference. As a general rule, architecture teams generally represent roughly 5 percent of the engineering organization. Ideally, there is also someone from site operations on the architecture team, especially as companies come to appreciate how difficult the site operations considerations can often be when it comes to keeping a large and complex site up and running.

Whether you promote your architects from among your senior engineers, or whether you hire architects from the outside, it’s important that the architects have the trust and respect of the engineering team. The architect is in an important sense representing the engineering team, and when they say something is feasible the team needs to know that was an informed statement.

As a product manager embarking on a new project, your first task is typically to identify the user experience designer and the engineer or architect that you’ll be able to work closely with throughout the product discovery process so that you can work together to identify a product that is valuable, usable and feasible.

If you’ve never had a chance to collaborate like this on the creation of a product spec, I promise you that you will much prefer this process to the old model of writing PRD’s and asking engineering to review and provide a schedule. You’ll also very likely see a dramatic improvement in the quality of the products you come up with.