Question: “We are back from the training and I need a tool or table to quickly explain to a work peer the key differences between a Product Planner and a Product Architect. Can you help?”

Answer: The following table summarizes the key differences between a Product Planner and a Product Architect.

For more information, please see the Blackblot Product Definition Team Model, the “Product Definition Team” chapter in the “Product Manager’s Toolkit” book, and download the evaluation copy of the PMTK Role Descriptions template.

Blackblot Product Definition Team Model

Question: “I am finding it hard to ensure that my market requirements are clearly communicated to all developers in the project team. In the perfect scenario, I assume this would be the responsibility of the Project Manager, but that does not seem to cover all the bases in our organization. Can you recommend some best practice guidelines for this?”

Answer: Your request raises two distinct questions:

  1. How can market requirements be crafted in an unambiguous and structured manner?
  2. Which role should communicate market requirements to development personnel?

With regard to the first question, creating a properly-written (from a formulaic/formal or natural language perspective) market requirement is accomplished via several sets of guidelines, models and templates that comprise Blackblot’s Procedural Requirements Management™, a methodology to create consistent and usable market requirements. For more information, please see the MRD Quality Metrics article.

With regard to the second question, according to Blackblot’s Product Manager’s Toolkit^® (PMTK) methodology’s Product Definition Team Model the Market Requirements are written in the Market Requirements Document (MRD) by the Product Planner. Product Requirements are written in the Product Requirements Document (PRD) by the Product Architect. For more information, please see the Product Planner Vs. Product Architect” article.

Accordingly, the Product Planner first communicates the market requirements to the Product Architect. The Product Architect then communicates the market requirements and the resulting product requirements to the Lead Developer (a.k.a. Project Manager or Development Team Lead in many companies). The Lead Developer communicates the market requirements, product requirements and the resulting technical specifications documents to the Product Developers.

As market requirements information passes along the line from Product Management all the way to Development it logically and correctly becomes less strategic and more technical, hence the unavoidable possibility of miscommunication and misunderstanding as to the original meaning of the market requirements.

So according to PMTK the task of communicating market requirements to the Product Developers is the responsibility of the Lead Developer (a.k.a. Project Manager or Development Team Lead).

The only recommendation that can be made at this point and based on the information provided in your request is that you be physically present (as a listener) in the meetings between the Product Architect and Lead Developer and in the meetings between the Lead Developer and the Product Developers in order to ascertain if the context and meaning of the market requirements is properly conveyed. Your continued presence at the meetings should help you identify the reason for the problem, following which you can take corrective action.

Question: “In the Blackblot PMTK Features Matrix, as part of the product planning process, do I list all the product requirements and all the market requirements of the product? If not, how do I decide which requirements to include? Should I only list the product features, but not necessarily the market and product requirements?”

Answer: Product features themselves are actual product characteristics; and the reality between market requirements and technical specifications. This means that product features transpire when both market requirements and product requirements exist.

By following the guidelines and precepts of the Blackblot PMTK Methodology™ you should first list in the Blackblot PMTK Features Matrix all the market requirements and all the product requirements of the product. Product features will be listed next.

The proper sequence of entering data into the Blackblot PMTK Features Matrix is as follows:
Step 1 – Product Planner enters all market requirements.
Step 2 – Product Architect enters all product requirements.
Step 3 – Product Architect lists the resulting product features.
Step 4 – Product Planner and Product Architect complete all remaining descriptive columns.

At this point the Blackblot PMTK Features Matrix should be complete and can be used as a very powerful decision support tool to help identify redundant or missing features, build product versions and roadmaps, and analyze and prioritize features. Another important goal is to verify the lack of upward or downward traceability between product requirements and market requirements.

Question: “How does Blackblot see the role of the Product Architect post-launch?

As the product expert responsible for the PRD, the Product Architect is predominantly project-oriented. However, throughout the product lifecycle there are questions around what the product is technically capable of. Also, if post-launch the Product Architect moves on to the next project and a PRD involving a new product, who fills the role of ‘technical product expert’ on the older products?”

Answer: According to the Blackblot Product Manager’s Toolkit^® (PMTK) methodology, the Product Architect role is part of the Blackblot Product Definition Team Model and responsible for creating the Product Requirements Document (PRD).

Through the PRD, the Product Architect articulates the product’s architectural and technical vision and structure, and specifies the product’s components and interfaces which create the features that the market requirements prescribe.

The product’s architectural and technical vision may change as technologies evolve and improve. For example, such technical changes which only affect the PRD of a product, but do not affect the MRD, are the replacement of rotary hard-drives with solid-state disks (SSD); or the integration of the new IPv6 internet protocol, to replace the aging IPv4 internet protocol, into software and hardware.

Accordingly, in the same manner that the Product Planner regularly maintains the Market Requirements Document (MRD) to reflect the ongoing changes in customers’ needs, so will the Product Architect modify over time the product’s technologies to create a more fitting and better solution.

All members of the Product Definition Team (which includes the Product Planner and the Product Architect) continue making their respective decisions throughout the product’s life-cycle.

Introduction
The Product Architect is a critical role that is responsible for product definition.   At technology companies this role is assumed by an experienced technical and business savvy individual who frequently interacts with peer roles in both product management and product development.

The Product Manager’s primary objective to constantly research the market problem, understand customers, and become a market expert is a colossal endeavor.  Equally challenging and rewarding is the Product Architect role which is entrusted with envisioning a solution that bridges technology and balances the company’s strategic vision with the market problem.

Modern markets are characterized by sophisticated and demanding customers and superbly designed products that are based on advanced technology.  In response to this phenomenon, the discipline of Product Architecturing and the role of the Product Architect have evolved to become more structured and formalized.  Companies nowadays completely rely on the Product Architect to transform ideas, technology, strategy, and business context into a vision of winning products.

Career-wise, the Product Architect role has become a highly influential fixture at technology companies as Product Architecturing itself has become prominent.  Very competent and creative individuals with deep technological expertise, business acumen, and a broad and unique skillset are required for this role, which has made it most respected.

This review describes the rising importance of the Product Architect role.

Product Definition Team Model

 
Background
Technology companies went through an evolution of roles in which the original job descriptions were much generalized and essentially an aggregate of several roles.  The cause for generalization was that the technology companies’ founders previously undertook financial, executive, technical, developmental, sales, and marketing responsibilities all upon themselves.  It was only natural for the technology companies’ founders to frame any individual capacity at their growing organizations as a reflection of themselves and how they personally worked.  The founders often did everything related to the product.  They understood the market problem, defined the solution, and developed the product – as individuals or team leads.

Roles at technology companies must be specialized nowadays due to scalability and/or complexity demands.  Based on the principles of the Blackblot PMTK Methodology™, product related roles are consolidated around the boundaries of Problem, Solution, and Implementation.

The relevant conclusion from the role consolidation is that the overall Product Delivery process, the making and bringing of a product to market, is comprised of three sub-processes:

1. Product Planning – Seeking, identifying, and articulating the market problem that customers need to solve.
2. Product Definition – (a) Devising a functional solution to the market problem and (b) designing product implementation.
3. Product Development – Implementing the design and manufacturing the product.

Product Delivery Process

The Product Manager (a.k.a. Product Planner) role serves the key task of product planning.  The role of Product Developer (a.k.a. Product Engineer, or Software Programmer, Software Developer, or Software Engineer in the software industry) is responsible for the task of product development.

In the absence of a dedicated and recognized intermediary role to perform product definition, technology companies wholly relegate the task of product definition to the Product Manager or to the Product Developers. Depending on the company and on the functional and technical complexity of the product being developed, some technology companies split the responsibilities within product definition between product management and product development, assigning to the Product Manager the responsibility of devising the functional solution and assigning to the Product Developers the responsibility of designing the product’s implementation.

This problematic allocation of roles and responsibilities was and still is being practiced by many technology companies.

 
Gap in Product Delivery
The Product Manager is utterly devoted to researching and studying the market problem and customers’ needs while the Product Developers are deeply focused on the technical and developmental aspects of the product.

The growing complexities of building technology products made technology companies realize that product definition can no longer be assumed by people from product management and/or product development.  A dedicated role for performing product definition was required to bridge the gap between the Product Manager and the Product Developers.  Accordingly, this internal dynamic inspired companies to recognize and create the discipline of Product Architecturing and the role of Product Architect.

Initially the newly formed role of Product Architect was responsible for the entire Product Definition sub-process, in defining the solution, the product’s functionality and also specifying the product’s architecture (designing the product’s implementation).

However, it was soon made evident that one dedicated role is insufficient to handle the product definition of functionally complex products and/or where intricate technology is employed.  Two roles are required – one role to devise the functional solution and a second role to specify the product’s architecture.  The Product Architect role was thus split into two variants that together performed product definition.

 
Types of Architects
Based on the internal elements of the Product Definition sub-process, the Product Architect role is fine-tuned into two role variants:

1. Functional Architect (a.k.a. Product Architect, Solution Architect, Business Analyst, Requirements Engineer, Requirements Manager) who is responsible for devising a functional solution to the market problem according to how the market problem is described in the Market Requirements Document (MRD) or in any other similar technique which represents the market problem as provided by the Product Manager.
2. Technical Architect (a.k.a. System Architect, System Engineer, or Software Architect in the software industry) who is responsible for designing the internals of the product (specifying the product’s implementation) in conformance to the prescribed set of measurable features which are outlined in the Product Requirements Document (PRD) or any other similar technique which represents the functional solution as provided by the Functional Architect.

Because of the precision brought about by the more acute definitions of the types of architects, Product Architecturing can be properly defined as a discipline which describes the arrangement and internal interaction of the product’s components that collectively provide the product’s aggregate functionality.  In lay terms, Product Architecturing is a discipline that is focused on the formation, structure, and design of a product.  The Technical Architect is thus the role that truly owns and is responsible for product architecture.  The primary deliverables of the Technical Architect are the product’s various technical specifications.

The Functional Architect and the Technical Architect roles both belong to the development team and depending on the maturity of product delivery practices at the company, there could be some overlap at times between these two roles or they can be distinctly separate.

In the software industry the Functional Architect is focused on features, capabilities, and scope of the product while the Software Architect is a very proficient software developer who makes technical and structural design choices relative to the product and dictates technical standards, software coding standards, operating and development environments, and technical infrastructure and metrics.

Titles, role assignments, and their combinations vary greatly among different technology companies.  At some companies the Functional Architect and the Technical Architect roles are both assigned to one individual who is titled Product Architect.  At other companies the Functional Architect and the Technical Architect are decoupled and owned by separate individuals with respective titles.  And at some companies the Functional Architect and the Technical Architect roles are partially or wholly assigned to the Product Manager, erroneously of course.

For historical reasons rooted in the interest of clarity and distinction, in the Blackblot PMTK Methodology™ the Functional Architect role is consistently referred to as Product Architect and the Technical Architect role is referred to as Lead Developer.

Roles and Responsibilities

 
Product Architect Role Description
The Product Architect (a.k.a. Functional Architect) has domain expertise in a particular technology or product type, from an engineering perspective.

The Product Architect is a tactical role that is owned by a product expert who creates a high‑level design for the product.  The Product Architect understands the market opportunity, interprets market requirements, and is well-versed in technology and development processes.

The primary deliverable of the Product Architect is the Product Requirements Document (PRD), which is a high-level description of the functional solution, its intended use, and the set of features it provides that address the market problem and satisfy needs.  Through the PRD, the Product Architect articulates the product’s architectural vision and structure, and specifies the features that the market requirements prescribe.  The Product Architect often contributes to other supporting documents including the product’s feature matrix, product roadmap, and technical specification documents.

The Product Architect must be able to communicate well with both external and internal organizations.  External to the company, the Product Architect communicates and works with contract development firms, technology partners, and customers.  Internally, the Product Architect communicates and works with organizational functions such as Engineering, Product Marketing, and Product Planning.  The Product Architect also acts as a communication interface between the product planning team and the product development team.

Product Delivery Process

 
Product Architect Skill Set
The following set of skills, listed in alphabetical order, is essential to the Product Architect role:

• Business Skills – Ability to comprehend the business context and market problem that drive the building of a product.
• Conceptualization Skills – Ability to create product architecture, and evaluate and foresee the applicability of diverse architectural designs relative to the product.
• Engineering Skills – Ability to advocate and relate to different product development methods and modeling techniques.
• Leadership Skills – Ability to rally and gain backing from internal stakeholders in order to build organizational support for the proposed architecture.
• Mentoring Skills – Ability to counsel teams and individuals to wholly understand and effectively implement the proposed architecture.
• Technology Skills – Ability to understand in depth, analyze, and select current and emerging technologies that are pertinent to the product and company.
• Visionary Skills – Ability to create and articulate architectural and technical visions for the product.

 
Product Architect Role Overview Table
The following table provides an outline of the Product Architect role’s general profile and a list of its key characteristics.

 
Summary
The Product Architect is an extremely critical and distinct role that is responsible for devising a functional solution to the market problem and defining the product feature set, which creates the correct user experience and allows the user to complete the desired task.

Product Architecturing is encompassing, dynamic, and multifaceted, and so are its practitioners.  Regardless of the actual title or the selected software development method that is being employed, the Product Architect is a key influential role at the intersection of technology, business, and design.  Companies’ and their products’ chances of achieving marketplace success greatly depend on a well-defined Product Architecturing process and very capable practitioners who possess a myriad of qualities.

In summary, the Product Architect is a key leadership position within the development team with this role providing the proposed product’s architectural approach and the required guidance to the product developers.  The Product Architect is also the bridge and interface between the problem space and the solution space – between product management and product development.

Gabriel Steinhardt
Gabriel is Blackblot’s Managing Director and a recognized international technology product management expert, author, lecturer and developer of practical tools and methodologies that increase product managers’ productivity.