Crafting Products Customers Love: The Art of Product Definition

Unlock the secrets to creating customer-centric products that deliver business results

No matter the size of your company, building great products requires an obsession with your customers. This entails defining products and features that will meet their needs, engineering scalable and usable services with a consistent set of APIs, and launching high-quality, operationally excellent products. None of this is likely to be a revelation to anyone, but enforcing standards across your organization and surfacing decisions for discussion doesn't happen on its own. It’s a discipline you can practice and a muscle you can build.

I firmly believe that it all begins with a common culture surrounding new product and feature introduction. This culture involves creating detailed artifacts (documents) about your product thinking and engineering designs, including review mechanisms for internal discussion and debate. Note that this doesn't have to be a heavyweight process. You can determine how complicated the artifacts are, how many reviews you require, and the breadth of the audience for these reviews.

Most companies are able achieve success with common templates and synchronous (in-person or live on Zoom) reviews with a “core” audience that reviews all major products & features. I don’t find it matters what tool you use to create documents (e.g. Microsoft Word, Google Docs, etc.) although ones that allow for collaborative editing/commenting work best, and ideally you standardize on this across the company.

I’ll also add that while it’s hypothetically possible to implement this kind of review asynchronously, being successful with this approach demands incredibly rigorous guidelines & expectations for both writing and reviewing. I’ve only seen a handful of “fully-remote by-design” companies implement this successfully (Gitlab’s culture of “handbook-first” communication being the most prominent).

To consistently deliver stellar products, you need a mechanism that upholds high standards across your company. This, in turn, fuels an ongoing cycle of learning and continual improvement within your product design process

I believe are the four critical elements of building and delivering exceptional technology products: product definition, customer feedback mechanisms, engineering design, and operational readiness. In this article, I'll cover the first two. And at the end of this post, I'll provide a template you can use to begin the product definition process.

Now, let's roll up our sleeves and dive into the first two of these crucial elements.

1. Product & Feature Definition

These are documents written typically by product managers, engineering leaders, general managers or even VPs. These should be customer-centric and describe the future state of the product, spelling out what will be available out of the gate and what might come as an add-on later.

Completing a product or feature document before you’ve written a single line of code forces one to slow down and define, “the problem you are solving for customers, the solution you are proposing, and why customers will use it.” (Colin Bryar, Working Backwards)

I recommend creating a set of standard questions that authors need to answer in these product documents. Some suggestions include:

• What customer challenges is it solving? Who is the audience for this product?

• How will customers get started with your new product/feature

• What will customers be delighted with/disappointed by?

• What does success look like?

• How this product works with your other products or services?

• What other third-party products does this work with?

• What’s the proposed pricing model at a high level (if applicable)

• How will you sell it (developer-led, sales-led?)

And as a special bonus, you'll find a template with these questions and more, along with detailed instructions on how to think about answering each question, at the end of this article.

Aside from creating these documents, establishing a structured review process is equally vital. I emphasize the importance of consistency without unnecessary complexity. The aim isn't to impede new product releases but to guarantee that each product aligns with your rigorous standards.

A. Pre-Review Preparation

The document author should be conducting pre-reviews inside their organization before having it reviewed at a more senior level. Similarly, if the product touches other teams, those teams should have reviewed and provided input before the final review. I don’t believe it’s necessary to be prescriptive about how these pre-reviews happen, but I’ve typically seen this done asynchronously, and it’s where collaborative editing tools like Google Docs can help speed things along. The expectation is that the author isn’t presenting a rough draft to senior leadership or to other impacted teams. Authors are expected to have taken the appropriate feedback and incorporated it into the final document.

B. Final Review Meetings: The Crossroads

Then, each “final” product/feature document should be presented to the appropriate level of leadership in a synchronous meeting, with cross-functional/cross-org representation to ensure you’re hearing from people outside your own organization.

At a high level, if it’s a major new product/service, it should need to be reviewed at SVP or C-level, with senior leaders from other peer orgs, but also potentially sales, support or marketing in the room to provide backup or commentary, and to hear the discussion. A more incremental/minor service and feature could be reviewed by solely by your own VP, with sales/marketing business partners and some select product/engineering leaders from peer organizations. The goal is to ensure you’re not solely “talking to yourself” in these reviews.

C. The Purpose of Reviews: Beyond the Surface

Reviews are not just visibility - they should not be considered “FYI presentations.” And reviews are not what you’d present to customers - which might be a couple slides or a video demo. The goal is for the senior executives to ask probing questions that make sure you’re building the right products for the right customers at the right time and it reinforces that you have a standard model for designing products and making decisions - which helps facilitate faster product introduction.

The document author should be prepared to answer questions about the proposed product or feature. Ideally it isn’t just the VPs/Senior Directors talking in these, but the individual product managers - we want people to “own” the products & features they’re proposing. If senior leadership isn’t convinced the product will be a success as defined, teams can come back with answers and an updated document (clearly indicating what’s changed) for a second round of review - or you can decide not to build the product if it’s that far off the mark. Minor questions/follow-up can be handled asynchronously (i.e. via email).

D. Setting the Foundation: Documenting and Approving

In many big companies products are first proposed in an annual or long-range planning process (something I hope to address in a future post). My opinion is that this detailed product definition & review process is just as important even if the product was a “line item” in a previously created annual plan. Work shouldn’t begin until this product definition document is created, reviewed and approved. This needs to become standard practice in every part of your org, and is the core skill you should hire for in Product Managers. This is also how you can handle out-of-band escalations (i.e. major new product ideas/requests) during the year. Someone wil

l have to write a product doc, put some thinking into how large it will be and what else on the roadmap it would disrupt, and then you can have both the product and roadmap conversation as part of the review meeting.

E. Streamlining Review Schedules

Depending on how many of these you have, one approach to help with scheduling would be to have standing weekly (or twice-weekly) product review meetings on the calendar, with the “core” required executives booked/blocked off. Then you slot the “next” product review into those. The expectation is that presenting teams move their schedule around to fit executives doing the review.

F. Post-Review Execution: Empowering Teams

One of the keys to empowering teams is that after a product is greenlit, it’s up to the team how the work is decomposed into epics, sprints, tasks & milestones. There are other mechanisms below that ensure the product gets built right, and that the team is on track for delivery, but variability in how each team chooses to operate on an implementation basis is acceptable to me, and encourages a feeling of team identity and control. I’m not a big fan of having product definition reviews turn into project or schedule reviews.

G. Extending the Approach: Other Document Types

Relatedly, you can start writing and reviewing pricing documents the same way. Typically in a product definition document only the proposed dimensions of pricing are laid out, and the more detailed analysis of price point, discounts for committed use, competitive analysis, pro-forma P&L for the service (if applicable) are done later. You can develop a pricing document template with your finance business partners. Naming Documents (for major new services/features) and Competitive Analyses could also be created and reviewed via this mechanism.

2. Customer Feedback Mechanisms

Any discussion on crafting products that customers adore and readily embrace must include a conversation about collecting customer feedback.

Your most effective means of gathering customer feedback is direct communication with them. This holds true for companies of any size, but it becomes especially vital for smaller businesses, such as those in the seed-funded or venture-backed stage, where customer numbers may be limited. In such cases, your product managers and executives should maintain frequent, direct contact with customers. I cannot emphasize enough the irreplaceable value of direct customer interaction—whether it's one-on-one, one-to-many, or through engagements at conferences, trade shows, or events.

However, a note of caution is in order: While the majority of your products and features should stem from solid evidence of customer demand, leave room for innovation— delivering features that delight customers, even when they weren't aware they wanted them."

A. Sales Feedback

As your company expands and achieves greater success, you'll increasingly encounter customer feedback filtered through your “field” or “go-to-market” team —comprising sales representatives, account managers, solutions engineers, business development and more. This feedback can come from both existing customers and prospective ones that sales reps are actively pursuing.

While this input can be incredibly valuable, it's essential to avoid falling into the trap of what is typically called “sales-driven development” - wherein you implement custom features based solely on the latest prospect or the demands of your largest customer at the moment. Striking the right balance between recognizing valuable signals and filtering out noise or single-customer requests is a complex challenge. In my experience, perfection in this area is elusive.

As your company grows, it becomes important to establish a structured process for sales to rank and quantify feature and product requests. Subsequently, your product and engineering teams must regularly review these requests, deciding which ones make it onto the roadmap, which require further research (such as reaching out to the customers directly), and which may not be implemented, at least not immediately.

B. Competitive Analysis

Competitive analysis complements, but does not replace, the insights gained from direct customer engagement & sales feedback. It can serve as an additional “compass” guiding product development decisions. This is the art of thoroughly dissecting your competition—scrutinizing their offerings, identifying gaps in the market, and assessing their strengths and weaknesses.

Competitive analysis isn't about merely keeping an eye on your rivals; it's about gaining deep insights that can drive innovation and set you apart in a crowded field. Small companies have product managers do this directly. Larger companies often rely on a dedicated team, well-versed in the nuances of the industry, to conduct competitive analysis. These experts serve as your detectives, meticulously studying your competitors' products, pricing strategies, market positioning, and customer reviews.

One crucial aspect of competitive analysis is staying attuned to market trends and industry insights, including analyst reports. Whether we like it or not, business leaders and executives often make purchasing decisions based on what they see in these reports, which position products relative to other choices in the market. By monitoring emerging technologies, shifting consumer preferences, and industry disruptors, you can anticipate potential threats and opportunities. It's not just about what your competitors are doing now; it's about predicting their next moves and staying one step ahead.

Another related, and valuable practice is benchmarking—comparing your product's performance and features directly with those of your competitors. This exercise illuminates where you're excelling and where you might need to catch up. Again, larger companies often have dedicated benchmarking teams, that the product teams partner with for analysis & response to findings.

C. Customer Advisory Boards

Beyond all the strategies mentioned above, if your company has grown successful enough, you can unlock deep and invaluable insights through a structured process with strategically chosen customers in a “Customer Advisory Board” (CAB). Typically, you select CAB members who are heavy users of one or more of your products and ensure they represent various industries, geographies, and company sizes.

Another important consideration when forming a Customer Advisory Board (CAB) is to balance the membership by taking into account the duration customers have been using your products. This balance ensures that you capture valuable insights from both long-time users and those who recently adopted your products. Long-time customers may have grown accustomed to certain limitations or complexities, which newer members can still articulate as issues that prospective or new customers might encounter.

The advantage of working with a CAB lies in the level of transparency you can achieve. Since members are bound by non-disclosure agreements (NDAs), you can receive higher fidelity feedback compared to discussions with sales prospects limited to public information.

One highly effective approach is conducting an intensive annual CAB meeting. During this session, every department within your company presents a sanitized, high-level version of its annual plan, outlining proposed investments for the next 12-18 months. Additionally, teams present questions to CAB members designed to stimulate discussion—for instance, 'Would you be interested if we built a feature like <x>?'. Subsequently, individual teams can follow up with CAB members to delve into more detailed questions arising from the CAB, guiding product definition further.

Another successful practice is holding an in-person CAB meeting once a year, providing valuable networking opportunities for CAB members. This event can either precede or follow your annual or long-range planning sessions.

To maintain continuous engagement and feedback, consider conducting roadmap reviews and follow-up sessions with the CAB periodically, such as quarterly meetings. These sessions prove invaluable for gathering ongoing feedback on business decisions and refining roadmaps as product design progresses.

D. The Un-CAB

Additionally, I often suggest that product managers consider conducting what I like to call an “un-CAB.” This involves reaching out directly to customers who, after evaluating your product, ultimately opted for a competitor's solution. While it may be challenging to identify such customers directly, you can employ a few strategies.

One approach is to engage with venture capital (VC) firms and inquire about the competitive technology being used by their portfolio companies. This can provide insights into why potential customers opted for alternatives over your product.

The key distinction here is that while competitive analysis examines competitors' products, an un-CAB allows you to gather feedback from customers who have actively chosen a different solution, shedding light on specific pain points and competitive advantages that may not be immediately evident.

Conclusion

In closing, we’ve covered two of the essential pillars of crafting top-notch tech products: product definition & customer feedback loops. Hopefully you enjoyed this post and learned something (if you have feedback, leave it in the comments, would love to hear it). In a future post I’ll cover the other two pillars of building products customers love - the science of engineering design & operational excellence.

But remember, it's not just about processes and checklists; it's about creating a culture of innovation and high standards. It's about being customer-obsessed, transparent, and adaptable. In today's fast-paced tech landscape, these disciplines aren't just nice to have—they're a lifeline. They fuel innovation, ensure quality, and set you apart from the competition.

So, as you venture forth, don't just follow these practices; embrace them. Make them part of your organization's DNA. Strive to create products that not only meet or exceed customer expectations - but set them. After all, in the ever-evolving tech world, the journey toward excellence never truly ends.

And for those of you who've made it this far, your bonus prize awaits in the appendix—a template for new product initiatives that you can start using today!

---

Appendix: New Product/Major Feature Template

<Instructions for new product/feature template: Instructional text in [italics] should be deleted after filling out the template. Text in <brackets> is intended to be replaced by the appropriate content (e.g. words, phrases).

General guidance: Focus on the customer (working backwards from their perspective). Document your assumptions explicitly in your answers for readers. The goal for this document is that any reviewer could understand what you are proposing to build, what customer problems it solves, and how it will be successful - from the document itself, even without you around to discuss it.

In general the template is are not asking for implementation plans (project schedules, phased releases, etc). Answers about implementation can include suggestions: “We might …“, “It is possible …”. The primary purpose of this document is to help the company decide if it should build something (and whether it should be built in this fashion/with these capabilities). This should be written from the future point-of-view when the new product is released to general availability.

Listed in this template are proposed required questions, if there are more that are specific to your initiative/feature, add them (in Q&A format) but do not remove any of required questions. In general, do not use bullets in your answers, write complete sentences (e.g. nouns, verbs, adjectives, prepositions, etc). Graphs, charts, tables, wireframes (if needed) should be moved to an appendix, summarized and referenced from within answers. Maximum length of template when filled out should be around 6 pages (but can be shorter)>

<Initiative Short Name>

Initiative Summary

[1–2 paragraphs that give a summary of the product and the benefits, designed for external consumption. A well written summary is one where a customer or other reader could read only this paragraph and understand what the desired outcomes are. Think of this as a miniature press release, or summary you would write in a short blog entry. If this is a new product, articulate how it will fit in the rest of the portfolio (e.g. this will be accessed via a new portal or SDK). If this is not a new product, articulate how this initiative will augment existing offerings]

Initiative Details

1. What customer challenges is it solving?
   [1-2 paragraphs describing the problem that a customer faces, which this product solves. Think holistically about the customer problem]

2. How do customers solve this problem today?
   [1-3 sentences describing existing processes and tools customers use today, and any challenges those present (cost, efficiency, errors, etc.)]

3. How will customers get started with your new product/feature
   [1-3 sentences describing how someone can start using this product/feature. If getting started is baked into the product itself, explicitly note that. Not a full description of the product features]

4. What will customers be delighted with?

   [What is the killer feature/use case that will get customers excited? How do we realize fast time to value (TTV)? What will this initiative do *really* well for our customers?]

5. What will customers be most disappointed by?

   [Note: If there are anticipated features that will be explicitly not part of the initial release, they should be described here, along with why we believe it’s ok to launch without them. This might include features in related services we won’t be ready with out of the gate]

6. What does success look like and how will we measure it?

   [Define specific success metrics and targets for those metrics over some reasonable period of time. Be as specific as possible, use quantifiable metrics]

7. What groups/functions inside a customer do we anticipate being the primary users of this product?

   [Articulate who will be purchasing this offering (and additional decision makers & stakeholders) and who the users will be]

8. What are the key outcomes or “jobs to be done”?

   [JTBDs (see link) represent the outcomes your users are trying to achieve. Describe them in 1-2 sentences. Repeat this for different personas if applicable

9. How does this work drive forward our customers' business goals?

   [Articulate how this will fit within major customer initiatives and transformations or contribute to key business goals. E.g. how this fits in DevEx strategy the customers are building or Infrastructure transformation]

10. What will the product not do?
    [Define what is out of scope for the product over a reasonable time frame that a customer might ask for/expect]

11. Does this product require additional functionality from other parts of the company’s portfolio for customers to see it as full-featured?

    [As an example, if you’re proposing additional functionality in Product A, but customers would expect additional features in Products B and C for this to be considered a full-fledged solution to their problems, describe that here. Detail about whether you do/don’t plan to build that functionality as part of this initiative should be in questions 1-5 & 8]

12. <Add other questions as relevant to your initiative>

    [example question “Q: Will this be available as a standalone download in the company marketplace”; “A: No. This product will be distributed as part of package <foo> which is already available in the company marketplace (see pricing Q for more)”)]
    
    [example internal questions about early-thinking around engineering or design elements can also be included here to give people an idea of the resources required (ex. “Q: Will this work with our existing back-end? A: Yes. Usage will be low volume, adding only 1-3 TPS to our back-end which already has significant headroom after <project refactor> completed last year”). Reminder: this is not a detailed scoping document, which will come later]

Market landscape

[Describe in sentences, using quantifiable data (numbers) wherever possible. Avoid weasel words/hyperbole (some, significant, a lot, huge, gigantic, massive) or speculation (“if we can get just 1% of market, etc”) where not supported by analysis]

13. What is the market opportunity?

    [Describe the scope/definition of the market and market size, as well as growth projections. Be concise and cite sources where available for projections. Additional data/detail can be referenced and contained in the appendix]

14. Are there existing or prospective customers who have specifically requested this capability?

    [List specific customers or customer segments, and include specific needs where possible (i.e. what problem they are trying to solve)]

15. Which customers do we expect to target?

    [Specify customer vertical or customer segment/size (enterprise, commercial, cloud-first startup …)]

16. Which of the company’s OKRs or strategic priorities does this advance?
    [If you’re not aware of any, acceptable answers include “N/A” or “none’]

17. At a high level, what are we thinking about pricing?
    [Answer questions such as do we anticipate offering a free tier, will this be included with another company offering or offered as a paid add-on, what dimensions are we debating charging on (e.g. cores, clusters, users, etc). For example - “We believe this should be a paid feature and are currently exploring charging either per developer or per cluster managers. Full pricing analysis and price-point will be done in a separate document.”
    
    Since pricing decisions will not be made in this meeting, it’s acceptable to not have all the answers for this question. If this is intended to be offered for free, just state that]

18. How will it be sold and/or distributed? Does this require a specialized sales motion?

    [This question is trying to get at whether this offering will be enterprise-sales led, will it rely on co-sell motion with a cloud partner, will this be SaaS-only pay-as-you-go model? See above comment re: free. It goes towards the adoption expectations.]

19. How does our solution compare to competitors (include do-it-yourself alternatives)?

    [Provide a high level analysis of the key players in this space and a prospective on how we would be positioned against them, what would our differentiation be, why would a customer purchase our solution vs theirs, are we coming from behind]

20. Why should we build vs. partner vs integrate vs acquire?

    [For the key outcomes & feature areas, provide a recommendation on build/partner/integrate/acquire opportunities. Integrate refers to opportunities to integrate within the existing company portfolio.]

Key dependencies and risks

[As a reminder, the scope of this document does not need to include implementation plans]

21. On what other teams or technologies inside of the company does this product depend?
    [Describe the technology and teams, and whether work is required of the other teams, or the dependency/team can be used “as is”. If work is required of other teams, this should be discussed and the general approach agreed to during the creation of this document. Formal agreement on resourcing can come after executive review of this document, if needed. Optional: Detailed table in the appendix]

22. What must be true for this to succeed?

    [Describe what conditions must be true for this initiative to be successful including whether the product needs to hit the market by a specific timeframe (conference, customer commitments, purchasing cycles) or with a specific minimally-viable feature set or compliance certification based on “hard” customer or industry requirements - including if you need functionality to be present in components/services outside your group (from elsewhere in the company]

23. What are the key risks?
    [1-2 paragraphs describing whether there are invention risks, execution risks, dependencies, pricing, funding, timing elements]

Supporting Information

[Add supporting information as necessary (graphs, charts, additional market analysis, mockups).

Break into separate sections, label (appendix A-Z) and reference from within main body of the document (i.e.. “We estimate the market for this type of product to be $100M growing at a CAGR of 13% over the next 5 years (see appendix C)”)

While not required, if there is a known/well defined phased product release proposal, it can be included here.]