Product 101 for Engineers

Why Product

• We need to know what to build
• We need to know why to build that
• We need to know why not to build anything else
• We need to know the tradeoffs on building any given thing vs any other given thing
• Talking to prospects and customers to understand their needs vs what they might state their needs to be is a skill
• Doing qualitative and quantitative research is a skill
• Translating those needs into goals, use cases, and requirements that can actually be comprehended by and built against by an engineering team is a skill
• Breaking down long term product vision into near and mid term stepwise (or parallelized) achievable product progress that is value generating at every step possible is a skill
• Balancing value (that we deliver) and friction (that we cause) is an iterative process, requiring constant attention
• Keeping engineering, marketing, sales, sales engineering, customer success, and support in sync does not happen automatically
• Making sure what is built is what was desired requires dedicated attention
• Balancing customer needs vs customer asks vs marketing requests vs sales requests vs input from potential customers vs support and maintenance requirements vs product vision vs competitive pressure vs business growth needs vs costs and margins vs founder desires is a full-brain job

The fundamental purpose of product is to make sure the most right thing is built, at any given point, by (1) optimizing all of those tradeoffs and (2) maintaining a path between where the product is and where we ultimately want it to be.

Functionally Speaking

Product Vision

In order to make decisions about what to build, we need some thesis about the world and something broken about it for someone (our persona) that we intend to fix. We need a statement about how we will manifest that in a product that will be shipped to that someone. And we need articulation of how we will ultimately change the world for that someone.

This set of statements serves as the bar by which we can say “no” to the infinite requests and demands placed on the team about what to build. Including those that come from the team itself.

This set of statements is not static. In the worst cases, it changes [apparently or otherwise] randomly and capriciously. Less worse is that it changes implicitly. Better is it that it changes due to existential risks and crises, but explicitly. Best case is that it changes explicitly due to learning how better to serve the needs of the users we serve over time.

Product Roadmaps

Most product roadmaps are just plans, of which only some part come to fruition.

• What’re we building right now?
• What’re we building next?
• Which things are being built for what reasons?

It gets better with context.

• How does each thing serve the Product Vision?
• How does each thing map to revenue (dollars in) or cost (dollars out) — does it expand an existing revenue stream, does it add a new revenue stream, does it depend a revenue stream, does it reduce costs, etc?
• What is the stage of the thing being built (MVP, alpha, beta, scaling, update, maintenance, etc)?
• What’s the cost of not building the thing?

It gets better with a roadmap.

My preferred visualization is a matrix with two axes with the ultimate thing (or set of things) which would realize the Product Vision being at the lower right hand corner — such that if we fill in all the boxes, we’ve achieved the ultimate aim. [See Building what you set out to build.] Like this.

The interesting thing about this approach is that, to a great degree, the order doesn’t matter. As long as all the things eventually get built. The actual order is determined by the market vagaries of what we’re able to build and sell in a given time frame sufficient to support and grow the business.

What we have to keep in mind when the Vision changes is what doors we’ve closed to ourselves based on the product and business we’ve already built and what doors are still open to us. In other words, what can and can’t be salvaged. In real life, our ability to pivot (and survive) is dramatically altered by these facts.

It gets best with an actual [Wardley] Map. That’s a topic unto itself, which Simon Wardley explains best. At this point we’ve leaked backwards into Product Strategy.

Product Strategy

The reason I’m putting this here instead of above Product Roadmaps is because, in the real world, Product Strategy isn’t usually done until pursuing a Raodmap derived from our Vision hits the messy world of Go To Market (marketing and selling things). And shit goes sideways.

A way to think about strategy is, given our Vision:

• How are we going to fill out that matrix?
• Which bucket of money will customers pay for our product out of — an existing bucket out of which they buy competing tools, an existing bucket controlled by a specific role that doesn’t buy things like our product, a new bucket they’re going to create, etc?
• What are we choosing to compete against — an existing market full of players, the top/bottom/middle of an existing market, a new market that we’re going to create and lead such that the alternative is to do nothing at all, open source things that no one thinks they pay for, etc?
• How does our Sales Strategy — top down, bottoms up, land and expand x inside, outside, field x enterprise, mid-market/commerical, SMB, etc — impact what goes on the Roadmap in what order?
• How do our Pricing and Business Model impact what goes on the Roadmap in what order?
• What are the things we’re going to look for to tell us that we’re on the right track vs not?
• What are the things we must build?
• What are the things that must be built in a specific order?

Product Development

This is the actual building process: the details of methodology, process, teams, communications, inputs and outputs, etc.

There’s always some process. Even if we don’t talk about it or use those words. Keeping track of these things and whether they’re working is an actual job responsibility. We need to be able to answer questions like?

• Are we putting things on the roadmap which are actually possible and can be built by the finite resources of time and labor available on some engineering team?
• Can we effectively take the line items on a roadmap and turn them into goals and requirements that can be built agains?
• Do we have backup plans in case of technical roadblocks?
• Is there an MVP that we can use to test the hypothesis embodied by a particular feature?
• Do we have enough people on different teams to maintain a reasonable work-in-process load without severe bottlenecks? (Getting a bit far into engineering management maybe.)
• Is progress being communicated to the rest of the company at the right intervals with enough details to ensure that dependent/downstream work is calibrated appropriately?

Product Research

Getting real life validation of Product hypotheses. Including, but not limited to:

• Putting wireframes or an early version of something in front of customers or other relevant persons for feedback
• Designing and running A/B tests for features
• Running surveys and collecting feedback form users
• Tracking user behavior
• Doing exit surveys of churned customers
• Doing competitive research to see how competitive products do things
• Doing market research to see if inspiration can be taken from other fields
• Running a Customer Advisory Board

Product Marketing

Depending on how we choose to organize the company, or who we happen to have on hand, Product Marketing sometimes rolls into Product and sometimes into Marketing. I’ve seen it done very successful both ways in companies of all sizes. No statements about how this has to be organized are legitimate.

Copying from Marketing 101 for Engineers…

Product Marketing is itself a wide set of disciplines. Roughly speaking, I categorize it as a mid-funnel activity — though depending on the company, it reaches all the way to the top (running campaigns and leading DG activities) and all the way past the bottom (acting as sales engineering and product) of the funnel, taking over many activities that might be considered sales engineering or product management.

Including, but not limited to:

• Messaging: all the words used to describe the company (complete overlap with Branding) and the product, the features, their functionality, the value, etc., for every medium and venue at which that’s needed — including in the product itself for things like prompts and tooltips and menu entry names
• Positioning: placing the company and products in the market landscape, deciding how to state the competitive position versus other vendors
• Sales Enablement: providing salespeople with the language and materials they use with customers, including things like call scripts and data sheets and objection handling and playbooks — as well as providing sales engineers with technical training on product/features
• Analyst Relations
• Public Relations
• Demand/lead gen support: providing or reviewing all the content, messaging, etc., for things like landing pages, ads, CTAs, etc
• Competitive Intelligence: keeping tabs on the competition (existing and emerging), what they’re saying, what they’re building, and keeping the rest of the organization informed
• Market Intelligence: keeping tabs on developments in the industry, especially the specific ecosystem that the company operates within, that have (or might have) a material impact on the company’s ability to succeed in the marketplace
• Pricing and Packaging: figuring out how best to price products, how to package them into tiers, given the competitive and market landscape
• Documentation and technical writing (only sometimes a Product Marketing function; more frequently directly in Product)
• Customer Marketing (sometimes its own specialty)
• Technical Marketing (sometimes its own specialty)
• Product : collecting customer feedback, establishing and maintaining product roadmaps, coordinating launches (sometimes these core Product Management activities end up being run out of Product Marketing)

Pre-Sales / Go To Market

Keeping Sales & Marketing abreast of the Vision, Roadmap, what’s coming and when, and any changes to previously stated plans, and managing their expectations (or behavior) — is a core part of doing Product.

We want our Sales and Marketing to be both maximally effective and honest in the process of doing so. Well, at least I do. In order to do that, they have to know:

• What to market and sell when
• Why specific things are built and not built
• What problems are being solved
• Who the problems are being solved for
• What the damn thing looks like and how to show it to people
• What doesn’t work and how to avoid showing the parts that don’t work
• What the value proposition is (more Product Marketing)
• How to talk about the thing (more Product Marketing)
• How to position the thing vs competition (more Product Marketing)

And we need to coordinate when things are going to land, alpha, beta, or get RTM-ed (Released to Marketing) for GA (making Generally Available, i.e. “launching”).

Product people are often part of the actual marketing and sales process at tech companies, and especially startups. They get drafted to give presentation, participate in sales calls, write copy, create slides and videos and other collateral.

Finally, the product itself is a vehicle for Marketing, and may be for Sales itself:

• What are the messages presented?
• What are the CTAs?
• Is there a free trial or demo environment?
• Can people self-convert to customers?
• Can customers upgrade/downgrade themselves?
• Are the things that users can do with the product that will gain more users?

Post-Sales

There’s some aspect of customer onboarding that’s a function of most products in and of themselves these days. Versus needing someone from the company doing all the installation and set up for you, although that’s definitely a thing too.

Figuring out the optimal way to do that and the amount of it that will be self-service vs needing some kind of consulting or service work are important decisions.

Support

Support usually starts with Product and Engineering, before it becomes it’s own function. In the long run, Product ends up in a feedback loop with Support about:

• Triaging bugs
• Slotting bug fixing and maintenance works into development cycles and planning
• Triaging feature requests that come in via Support
• Providing features that help Support do it’s job, like a debug mode for some function

Customer Feedback

Product must keep track of, proactively acquire, and provide channels for customers to give feedback about both the product in their hands and the roadmap (where possible).

Growth

Copying from Marketing 101 for Engineers…

Growth is a somewhat nebulous term that comes down to growing, or increasing the velocity of, the funnel. The term derives from consumer-oriented product-driven companies where the vast majority of prospect-user interactions with the company are through the product/website/app and the act of creating/finding “virality”, “flywheel”, or “network effects” is a function of engineering and optimizing user experiences for that purpose.

Growth is oftentimes considered its own discipline and, sometimes, its own line of business with it’s own marketing, product, engineering, and operations staff that experiment with and A/B test all aspects of the user experience leading to conversion and expansion, as well as things like referral marketing.

In my decidedly old-man-shaking-fist-at-sky mindset, this isn’t a discipline. It’s a dedicated funnel team that’s usually led from product and run like an independent operating unit. But every generation needs to feel special. So have your mantle.

Partnerships & Integrations

Sometimes core to the Product Strategy, or the Business Model, or the Sales Strategy, or just to have any shot at making money, is to build things that integrate with other products.

The amount of effort and depth of integration has to get decided on and justified relative to the Product Vision, like any other feature.

Business Model

Sometimes what gets built is directly dictated by the Business Model and sometimes what’s been built directly dictates (or limits) it. This is a never-ending chicken-and-egg tension. Get over it.

At large organizations, Product Management involves building the business case for a new product that we want to built and pitching it internally to get the resources to go do so.

At some companies, Product Managers own P&L and are actually measured on the business generated by a their products.

Reading List

• Wikipedia on Product Management
• The Three Jobs of Product Management
• What It Takes to Become a Great Product Manager
• Tom Tunguz’s blog posts on Product
• The Product Matrix
• Minimum Usable Product
• AWS Lambda — a lesson in using product strategically
• Product, Marketing, and the Art of Managing Expectations
• Marketing 101 for Engineers
• Sales 101 for Engineers

Product 101 for Engineers was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.