The Language of Product

February 2014 — By Kris Gösser
This document is written for those interested in the world of Product. It is primarily centered on the software industry, but can extend to others. Comments and feedback can be sent to kgosser@gmail.com.
  1. Deliver...the right products
    to the right market
    at the right time
    in the right order.
  2. Learn what you don't know, execute on what you do.
  3. Ensure everyone knows what's in it for them.

Product is an often misunderstood business role. As a functional business unit it has varying definitions between companies. Its charge is broad, as illustrated in our opening remark. You do not find as much academic literature or pop business books, pundits or gurus in the space as with other disciplines.

In fact, young businesspeople are usually unaware of the role unlike the popular disciplines of Sales, Marketing, Management, Finance, Design, or Engineering. Scroll through any typical American undergraduate enrollment catalog (I'll choose Carroll University, my alma mater) and observe the course attention to business roles except Product. Even the best schools, like Stanford and Harvard, only provide graduate emphases in business, to which Product is normally a single course subset of an MBA program, or an MFA design-centric degree. Only a handful of institutions, like Northwestern or Carnegie Mellon, have isolated Product as a large enough business discipline to warrant a focused curriculum spread over two years.

There are two ways to interpret this. The first and novice interpretation is higher education doesn't really "get it". I used to think that when first thrust into the role of Product fresh out of college. I felt unprepared. But I've now come to understand that is wrong, and the second interpretation is more accurate.

Product is the intersection among key parts of a business. It is the liaison between different functional teams. It is integral not just to the What and How, but the Who and When as well.

Product doesn't have a specific college program in the same way there isn't a CEO School. That is not to say those in a Product role should be elevated to the importance of a CEO. Instead think of Product as a multi-disciplinary role charged with excellence across several "different hats". It is difficult to craft a Product pedagogy because the course content would be immensely broad, which would lead to light skimming of a subject matter. The best one could do is learn tactics and tasks—or get an MBA or teach yourself in the workplace.

All this to say that learning Product is better done via first-hand experience. And that is what I have done. The intent of this piece is to share the personal learnings from the last seven years of my career journey.

Make no mistake, Product is an important component of any successful business, whether tackled by someone orthogonal or those with titled distinction. Seven years ago I started as the former and have since transitioned to the later through baptismal by fire. This document is a collection of models and ideas I have developed while assuming many different startup roles—from marketing to design to engineering and beyond—which gradually morphed into an official Product role.

Being A Linguist

The purpose of a business is to provide goods or services consumers will purchase at a profitable price. To get there, the business must ask itself the Five Ws: Who, What, Where, When, Why (and How). Product can play a part in each question. Just a few examples:

In broad terms, 5W answers fall under the areas of Business, Technology, and Design in some fashion. Since Product plays an integral part in answering each question, I argue that it sits at the center intersection of those categories.

Product connects Business with Technology and Design by making sure the right thing gets done. It connects Technology and Design to make sure the thing gets done right.

With Business, Product must understand markets and market research, the sales process, revenue models and pricing strategy, channels and distribution, competitors and competition.

With Design, Product must have empathy for the customer. It must understand the Job To Be Done and situations, the problem, technology constraints, intentions, motivations, cultural implications, and have good taste.

With Technology, Product must understand complexity, both how to anticipate and manage it. Product must be aware of constraints and dependencies. It must work with vendors and partners. It must be sensitive to operational output. Most importantly, it must give clear guidance on the problem being solved and why it matters.

This is no small feat. We are asking someone to understand different worlds with entirely different models of thinking. To be in Product means to make decisions and manage people and processes across all these categories. How does one do it?

I believe the best approach is to be a linguist.

Ultimately, the Product role can be summarized as a translator between these very different worlds. Take one vocabulary set and match it to another, then synthesize the key terms and models. As the liaison between different roles, Product helps a company gel around common goals as identified by management. It is the conduit between which strategy flows to execution.

Each discipline has its own unique vocabulary set. I say this in a broad sense. Words, terms, phrases—they all mean something important to that group. I view each set as a toolbox full of tools because the set is nothing more than words to help a group do tasks. I see it as my responsibility to understand what a screwdriver is, a hammer, a saw, etc. With each new group I encounter, the first action I take is to identify a vocabulary list, then find definitions. The value Product brings is conceptually matching each list with previous lists.

After all, what is Finance other than assets, liabilities, debt, etc.? Or Design other than shape, color, grid, contrast, etc.? And so on. Of course, I'm generalizing. Each term is a nuanced concept important to its constituent. Each term becomes a world unto itself. But exploring those nuances is the challenge to be relished.

Being good at Product means being good at communication.

You can't communicate effectively between different functional business groups without understanding how to translate their vocabulary. Thinking of yourself as a linguist is an important mindset to being successful.

Core Responsibilities

What is the Product team ultimately responsible for? At its heart, Product is responsible for executing on what's known, and learning what's unknown.

Several core responsibilities directly relate to the start, middle, and end of Product's normal cadence, i.e. projects. They speak to the input, output, and journey in-between.

1. Understand the Market and Problem

Steve Blank talks of Nine Deadly Sins but it is the first one that crushes hopes of success the quickest. Knowing your market and the problem they have is essential.

Deadly Sin Number One is committed when one assumes what customers want. Assumption is best done with lack of data. As a member of Product, you must "get out of the building", as Blank says ad nauseam, and speak with customers. What he is really saying is to get data so you aren't making assumptions. Talking to people is basically how we best generate that data.

You must have constant dialogue with people who the product touches so you can build enough qualitative data to act quantitatively. Product confidently posits to Sales what customers genuinely want (and will buy), thus defending the roadmap. Product confidently guides Design through the best approaches to design decisions based on customer feedback. Product confidently advises Technology on implementation details knowing what works with customer contact.

2. Communication

Professor Osmo Wiio famously and humorously observed how human communication usually fails except by accident. One could argue the phenomenon is amplified in the workplace.

Product provides maximum value when it facilitates and translates communication between two different parts of a business. By and large Product's primary responsibility is to ensure that a piece of information one team has is communicated to other team members dependent upon the message.

Product communicates front-line insight from Sales to the Design team. It communicates timelines and roadmap priority to Marketing. It reminds all team members the market and customer, problem and solution.

3. Product Vision, aka Roadmap

Once the executive team has set the company in a specific direction, it is up to Product to translate objectives and goals into a product vision. How do we get there? In what order? What will differentiate? What do we say yes to, what do we say no to?

Your vision manifests into a roadmap, the physical representation of your perspective critical path. The roadmap minimally contains milestones, priority, and up-to-date timeline estimates. Most importantly, Product can defend roadmap decisions by pointing to customer conversations, market research data, and internal consensus. Curating a roadmap is vital to a team's success because it becomes the solid foundation different teams can refer to when answering the question Why are we here?

Plans change, however, so communication ultimately plays a vital part in a successful product vision. Company culture must allow for strategic flexibility based on continual data gathering. If a new bit of insight dramatically alters Product's vision, it should feel free to update the roadmap. But transparency and speed are crucial communication requirements when a change is made.

4. Delivery

"Real CEOs ship." — Steve Jobs

A famous quip by a revered CEO that trickles down to us. The head of Product is ultimately responsible for meeting deadlines and providing delivery of product launches and incremental project releases.

5. Team Coordination

As a subset of communication, Product is responsible for coordinating activity between separate groups. It usually assigns duties and gives priority to tasks. When one group has a dependency on another, e.g. Technology requiring Design's wireframes to proceed, Product ensures communication and facilitates the cycle back to Technology.

Team coordination usually takes the shape of Gantt charts, task assignment, or document exchange. Plus there are many new and radical ideas beyond the standards charts and docs entering the profession as we speak. An effective Product team ensures everyone working towards a specific target knows what they should be doing, when, and to what level of effort.

6. Defining the "What"

The community has been split on the value of "specs". On one hand, traditional document specification is invaluable when projects require coordination among many different groups. Specs are a proven way to ensure vision is properly understood. Large, multi-national organizations generally have greater risk with miscommunication and erroneous projects than the speed at which they deliver.

On the other hand, the time requirement and drudgery make small teams pull their hair out. Startups loudly proclaim specs and documentation to be wildly wasteful, which is true when the number of individuals involved can be counted on one hand. With a group of three, communication of project requirements is more easily achieved by simply talking and jotting down a few notes. A startup generally sees greater risk with time constraints preventing fast turnaround than with erroneous miscommunication.

It's really a matter of where your company sits on a risk continuum. Awareness empowers Product to fit to the style of documentation needed.

Regardless of company scope, one thing is clear: documentation is a pivotal way to ensure clarity in communication before and during projects. We are responsible for defining projects, and documentation is simply the output of that job. It doesn't matter the size of your company—2 people or 20,000 people—the individual in charge of Product is responsible for defining the "What". The deliverable doesn't matter—a Post-It note or 50-page spreadsheet—Product should be graded on how well team members understood project definitions.

7. Consensus Building

We've talked about how Product is a liaison. They are the master internal negotiator. In some respects, the head of Product is closer to the head of Sales than any other discipline because he must be constantly selling internally. Daily, he has to sell the product vision, roadmap, and project scopes.

Building internal consensus often falls to Product. It should be embraced.

Starting Knowledge

What knowledge is required for someone to get started with a new Product role? Three key requirements stick out as musts.

The Job To Be Done (JTBD)

Job To Be Done theory states all consumers hire a product or service to do a job for them. Marketers and businesses should therefore segment not based on demographics or psychographics, but on the consumer's situation when he or she attempts to complete a job. Successful brands build a product or service around that singular job to be done. When an entire company’s weight is put towards it, the brand becomes what’s known as a “purpose brand”.

IKEA is the quintessential example. It has never been copied because it doesn’t segment based on demographics or income or whatever else. It re-segmented the consumer furniture market by focusing on a singular job: quickly furnishing a room/apartment/house/office with well designed products. The entire company is integrated towards that end. Manufacturing, shipping, catalogs, websites, even the buying experience. And don’t forget about the brand-famous home assembly process. You can learn more about Clayton Christensen‘s insight on IKEA in this 5-minute video.

The “milkshake example” is the key moment where Christensen and his colleagues flushed out the theory. It’s the most widely talked about anecdote available. This 5-minute video of Clayton giving a snazzy lecture recaps it well.

Knowing the product's JTBD is priority number one. Without it, talking to customers, which is the most important activity, will be rudderless.

The Market

Understanding the market, whether situational or demographic, gives Product a decision making edge. If you understand the properties and attributes of your market, you can more intuitively see the product vision, which in turn allows you to more effectively draft a roadmap, set project priority, and avoid costly mistakes.

I have found knowing the market is harder than we think. Often we believe we know when we don't. It can potentially take years to learn the nuanced intricacies of your specific market.

Familiarization with a market is often why entrepreneurs with that background have a higher probability of a successful exit. Time and energy is saved because learning requirements are reduced. Critical mistakes are likely avoided from past situational experience.

Similarly, successful businesspeople tend to stick within the same industry even as their career evolves. It's rare to find an Oracle salesmen jump to selling Boeing jets as opposed to hopping over to SAP. Or why US-based consumer food marketers don't find themselves re-inventing Ford's China strategy.

The same is true of Product. Knowing your market gives you a head start. At every job, audit your knowledge of the product's market. If you are in any way unsure of key properties, it is important to spin up as quickly as possible.

The Macro Landscape

There will always be a macro dynamic enveloping your company and product. Let's examine an illustration of the enterprise software world so we can have a common reference model.

At the top are the AKEs, All Knowing Entities, enterprise software platforms that try to capture every part of an organization. These are generally companies, not products. While several exist globally, Forrester highlights six as the best and biggest examples: Oracle, SAP, Salesforce, Microsoft, IBM, and ADP. There are others, like Sage, Netsuite, Worday, and Infor just to name a few, but ultimately they span only a few verticals instead of an entire enterprise. Relatively speaking it's a small group and very hard to break into. One could seriously consider Google to be a new entrant and poised to enter the realm of the six. Likewise, one could humorously consider the NSA to be the market leader.

The highest tier tries to reach across an entire customer's business. You will see product lines for product management, manufacturing, marketing, HR, and other functional units. The CEO or CIO are usually the buyers.

The next tier down are software platforms tailored specifically to the individual functional unit in context. For example, SuccessFactors is an HCM, or Human Capital Manager. (SuccessFactors was recently acquired by SAP—an excellent example of an AKE rollup!) It manages the entire employee lifecycle, as well as other HR tasks like benefits and payroll. Other categories in this tier are CRMs (Contact Relationship Management) for Sales, or MRPs (Manufacturer Resource Planner) for factories. You might find some vendors, while not full-blown AKEs, span several categories. Workday is a fine example as a suite that spans both HCM and FM (Financial Management). The CIO is normally the buyer at this level, but VPs might fill the role as well.

The third tier starts to split off into software that caters to narrower teams within a business function. Staying within HR, Talent Management (TM) is a good example. TM is usually a single team within HR charged with very specific duties like acquiring talent and on-boarding new hires. Certainly the vendors a tier up provide products that fit this team, but other vendors specific to this duty exist too. Halogen is an example of a leading independent vendor.

Usually a Director is the most likely buyer at this tier, as you'll find individuals like the Director of Talent Acquisition. Certainly higher up individuals can still be buyers as well.

Similar models analogous to TM underneath HCM exist with each business function across the board, for example payroll or benefits management. The fourth tier and lower start to get more contextually specific, however.

Let's stick with HR. Under TM exist tools that help individual duties of Talent Management. With the task of finding candidates and hiring new workers, the older category of Applicant Tracking Systems (ATS) exists. We find Bullhorn or Jobvite as independent examples.

Each subsequent tier lower, the closer we get to what's called point solutions. These are individual software tools that solve specific problems. Often they aren't platforms. "Sourcing" is a known category of software that sits at our imaginary 4th tier as it applies to acquiring talent. An ATS would manage all the sources, but there are many different methods of sourcing. You can hunt with resume scraping, like Scavado. You can pull candidates in via job boards or aggregators like Indeed. Social media is a source of candidates, yet the industry is still figuring out the best way to do it. Talent communities like Ascendify, yet another emerging category unto itself, sources candidates by creating a virtual koi pond. My personal favorite new sourcing tool is Sourcing.io, a novel way to find technical engineering talent.

Interestingly enough, the farther down you go the closer the end user and economic buyer become, a la similar to a B2C model. Know this so you don't make business model mistakes. Remember SuccessFactors? Prospects can't simply put in a credit card and start using the product. Acquisition is a complex enterprise sale spanning months of conversations and negotiations. A contract is involved, usually worth millions. One tier down, Workday is still a buying process requiring human intermediaries—i.e. Sales—to become a customer. But the lower you go, the more we see examples like Sourcing.io, where an individual can put in a credit card and be charged $95/month.

It is crucial that Product understand where they fit in the macro landscape. If not, blunders all over can occur: you talk to the wrong "customers", you improperly prioritize features, you aren't properly measuring how projects impact ROI.

Draw your macro landscape and identify the category your product is in. We're all in some category—that's the definition of a market. So label yourself and test to make sure that is indeed the case. Don't go to battle without this knowledge.

The task is daunting. Take a look at this 2014 assessment of just the marketing software landscape—950 vendors!

Product, Meet Design

The majority of this document saturates a business tint. One thing should be absolutely clear, however: I am driven by design.

I'm a true believer in design-driven organizations, though to what degree is dependent upon the business size. Startups in a discovery phase don't benefit from the purity of design leadership as a mature company serving a mature market. Still, the most tangible lesson from Apple all businesses can learn is the value of a design-drive process.

Design is my formal training and the domain to which I have the greatest intuitive thinking. I solve problems with a design-based approach. I love the way it impacts people’s everyday lives.

Each domain has its own world view. Different disciplines give different mental models, different ways of approaching problems.

STEM world views have been increasing in societal value since the Industrial Age, but I argue diversity of mental models is more important. This is why Art majors are intriguing to me: they approach problems in a wholly unique way. Regrettably, society—more specifically the business world—doesn't appreciate their world view. Probably because in Art school they are taught to only be artists, not members of a capitalistic system. I wish their Art schools coached them to recognize the economy doesn't allow for much personal success if all you are is an “artist”. It's too bad because board rooms, marketing cubicles, and tech pits could benefit from the taste and empathy Art (and by extension Design) brings to the table.

Design’s world view is drastically undervalued and underutilized in the work place. I believe the reason is due to designers thinking their role is to work on traditional “veneer” type work. You know, “creative stuff” like posters and billboards. I also blame colleges for this. Too many students I mentor think their role upon graduation is making collateral in Photoshop and that's it.

Design isn't just about creating pretty things. It is also about crafting something—a process, functionality, utility, or workflow—around human intent.

Instead, design is best served as a compliment to a primary skill in either business or technology. Marketers market better and engineers build better when they have the taste and empathy that comes with a design point of view.

This is why I find Product a liberating canvas. As a designer, I'm able to more greatly impact the success of users because I'm more involved than just the tactical output of UX or UI. I can apply my creativity to a strategic process, and that's exciting.

In the startup world, I support the trend of hiring “product designers” instead of just “designers”. Traditional UX or UI designers are still valuable, to be sure. Companies employing someone who excels at the typical tasks of interface and graphic design have an envious asset. In fact, those skills are so important that they are prerequisites for product designers. The key insight is the emerging priority within startups that designers should be involved in a larger process. They should take on more responsibility across several roles because of their unique creative skill. In essence we are seeing designers organically assimilate with the traditional product crowd, and I find that only positive.

I’m an active mentor to college students and junior designers in the Milwaukee area. More than ever I overemphasize the importance for them to consider themselves a designer second to another skill. To me, Product is the best spot for design-driven individuals to employ their skills.

Activities

What follows is a collection of activities Product should do at certain intervals. Obviously there are some tasks that should be done daily and some tasks that should be omnipresent. But doing everything all the time is a recipe for failure, so I like to chunk certain duties by specific time frames.

Prioritization of activities is a fine art. A lot depends on the business context we're within. With enterprise software, I found myself purposefully neglecting common activities you'd find a consumer mobile app product manager doing. And that's ok.

I think of tasks within the metaphor of Earth's atmosphere. Hovering the proverbial 30,000 feet above is the mesosphere, which is like yearly planning. You want to see the big picture, take a step back, and think. As you descend to the stratosphere, your focus narrows to quarterly intervals. Eventually you do things every month, but then as you near the ground you group in weekly stretches. To me, the week interval is the most important. It's the heartbeat of one's job. Just far enough in advance that you can see where you are going and can change course if needed, but not far enough to see across the horizon. I manage my life by weeks. Lastly, our standard daily tasks are like the terra firma foundation upon which all else rests.

Yearly

Theme: The Big Picture

Quarterly

Theme: Pulse on the Macro Landscape

Monthly

Theme: Direction Updates

Weekly

Theme: Development Heartbeat

Daily

Theme: General Tasks

KPIs

Key performance indicators, or KPIs, are quantitative definitions of success used to measure progress or score results. A similar concept are objectives and key results, or OKRs. Rick Klau from Google Ventures speaks to OKRs in this presentation.

KPIs are hard to do quantitatively, so we often need to measure them qualitatively. Here are the ones I measure myself by:

There are some quantitative measurements, though.

Product Organizations

Traditional Product Organization

A traditional product organization is linear and specialized. The team dynamic is similar to a phase-gate approach found in waterfall management. We typically see four distinct roles, outlined below.

The Product Marketer role is most dedicated to the outward set of tasks, meaning customer- and market-facing. She looks for "whitespace" and tracks competition. She talks with customers and prospects to intricately understand the Who and Why. The Marketer is usually the lead on pricing, promotion and distribution. Her outputs flow to the Product Manager.

The Manager takes inputs and crafts them into a plan. He usually takes charge of the What by gathering requirements and creating documentation, managing a roadmap and curating a backlog. He controls the When by being responsible for priority decisions. The Manager is the bridge between outward and inward concerns. He also talks with customers, but for different reasons than the Marketer. Whereas the Marketer is continually testing hypotheses related to the Who and Why, the Manager talks with customers or prospects to test hypotheses related to the What and When. The Manager's outputs are usually projects for the Project Manager and Business Analyst to refine and complete.

A Project Manager takes direction and coordinates a team towards completion of a defined end state. Progress feedback flows up to the Manager, which is used to continually adjust timelines and expectations.

A Business Analyst is an expert on the How. He refines projects and gathers further requirements which is important to the Project Manager's success. He is deeply engaged with analyzing the market, vendors, partners, and company dynamics. His feedback is an important input to the Manager as his insight impacts roadmap vision and business strategy.

Lastly, the Manager keeps the Marketer up to speed on delivery capability, timelines, etc. He provides the Marketer with content or resources from finished projects to use externally.

With traditional product organizations, I think of a single continuum where one side is outward facing, or the market, and the other inward facing, or the company.

For the sake of completeness, I tend to see these as tasks commonly assigned to each classic role, whether as the lead or in a supportive fashion to another group.

PRODUCT MARKETER

PRODUCT MANAGER

PROJECT MANAGER

BUSINESS ANALYST

Modern Concept — The Product Owner

Certainly with startups or small teams you can't necessarily have (a) individuals as hyper specialized as the traditional organization of a corporation; or (b) one person who does all those jobs. The Product Owner (PO) has emerged as the preferred way for small teams to manage a product. The PO is a single person who cross-cuts many of the aforementioned roles. It is tightly tied to the agile software movement, but you don't have to be beholden to some consultant's agile methodology to appreciate the organizational value of a PO.

In this concept, the PO has an executive sponsor. The Executive is responsible for setting business strategy. She can be any title—CEO, COO, CMO, Director of Technology, whatever. Her roles are to lead the Who and Why. The Exec's game plan is light but a basic requirement for the PO to function.

The PO is responsible for the functional success of the product. Many of the roles across traditional titles are roped into this single person. He is both inward and outward facing because tasks he is responsible for exist on both sides of the spectrum. He has to meet the functional needs of customers and strategic needs of the business.

Again, the PO is not responsible for the business strategy. That is the Executive's call. It is the PO's job to translate that strategy into a vision then guide that vision to completion. The PO isn't charged with setting the Who and the Why, but understands it fully, and even helps contribute to it heavily by giving initial and constant feedback to stakeholders. Instead, the PO is primarily responsible for the What, When, and How.

The PO has the right to say Yes or No to projects. It is important that the Executive grant the PO that ability.

In a larger organization with a more complex product, a hierarchy of POs develops. Generally there is one Chief Product Owner who becomes the liaison between all subsequent POs and their respective teams.

The Product Owner has a distinct workflow that helps illuminate what tasks might be asked of him.

The PO is concerned with "output" and "outcome". He is responsible for both. They are connected because output impacts outcome. Output is basically Project Management in the previous definition list, while outcome is the impact on stakeholders:

After the Executive sets the business strategy, the PO translates it to a product vision. The vision is his; he owns it. It feeds into an ongoing list of project ideas that might help the realization of the vision. That list is called a backlog.

Both the vision and the backlog help inform the roadmap which is also the PO's to own.

The PO takes a look at the backlog and decides project priority. Talking to customers is the crucial step in this process. A common failure point is improper prioritization of projects due to guessing what will truly add value to the business strategy or meet the vision. Don't guess—talk to your market.

After deciding backlog priority, he assigns a specific number of projects to his team of developers and designers who conduct the building process. Generally a good PO will delegate properly and trust his team—he's relatively hands off. But he can jump in to help on design decisions, mock up wireframes, QA results, or wherever help might be needed. He should be prepared to handle anything.

After project completion the PO obtains feedback from the team, customers, and prospects. He analyzes that feedback and disregards the unimportant stuff, but elevates the relevant feedback to new content in the backlog. Part of that process is pruning the backlog so that it doesn't grow into a behemoth. Pruning is useful because, presumably, you're constantly learning something each iteration. The new knowledge should impact the backlog priority—both changing the priority as well as marking some items as worthless.

This cycle is what the PO should be doing weekly, but he should never lose sight of the higher level responsibilities:

Extras

Source and Filter: Go Wide Then Go Narrow

Most of what Product does can be boiled down to the relationship between sourcing and filtering.

Everyday, we primarily do two things. We make decisions and communicate. Sourcing and filtering are two actions that strongly impact both.

Sourcing is the act of gathering as much data or information as possible. Whether you realize it or not, you are going through the exercise of sourcing every single day. You source feedback from team members and customers. You source insight on competitors. You source data from cohort analyses. Sourcing gives you the backing needed to eventually make decisions.

Filtering is the act of organizing and categorizing the sourced information in a way as to which it can be useful. Eventually part of the filtering process is making actionable decisions with the information in front of you. You filter by deciding which feedback points get placed in the trash and which productized as features in the backlog. You filter by recommending reaction to a move made by a competitor. You filter by making roadmap changes based on insight from a cohort analysis.

Finding a balance between being in a sourcing mode compared a filtering mode is helpful to heightening your efficacy. They are two very different modes of thinking. I do believe you can handle thinking in both modes at the same time. But I have seen tension and poor performance occur during collaboration when a team judges interaction through one lens when it was actually meant for the other. For example, immediately critiquing whether a feature is complex or not is harmful if the other team members are going through the exercise of sourcing feature ideas. Filtering when everyone else is sourcing stunts the conversation.

A more human expression is "Going Wide" and "Going Narrow". In effect, we're constantly trying to widen ourselves before we begin to narrow. Using these terms has proven useful with others.

I have found it helpful to set context for others during a discussion. I'll usually mention that "we're going wide" or "trying to narrow" if tension arises. Mostly though, I try to not limit others from going wide. It's silly to limit ourselves from creative ideas. Where tension sparks, though, is when others interpret the act of going wide as harmful because they think we're attempting to go narrow. So more often I'll leave the discussion open but interject to clarify one's opinion as going wide for the rest of group so they interpret the thoughts and suggestions appropriately.

Macro vs. Micro Designation of Projects

As a product owner within a small startup of 10 individuals, I found it difficult to find a common framework to describe projects to the business team. Usually the lack of a framework means a lack of categorization. Eventually I found a lot of success by instituting a binary project categorization I dubbed Macro vs. Micro.

It starts with the assumption that all projects will fall under one of two categories. The way I would handle project communication with the rest of the team stems from its category.

Macro projects are large strategic initiatives spearheaded by business colleagues. They have sales or marketing implications. These projects generally fill out roadmaps. Prioritization is inspired, if not determined, by the business team's input.

The key property of a macro project is proactive communication. I strive to gather business requirements long in advance and work between teams to finalize scope, features, and timelines. With macros, the business team knows exactly what they are getting and when.

Usually macros were offensive moves and benefited from marketing outreach. In enterprise software, that means press releases, media hits, communication to key stakeholders, etc. This requirement was a big reason why proactive communication and planning was imperative for the project to be successful.

I found a single development team only had the capacity to handle one macro at a time. Only periodically was it a good idea to juggle two macros at once. For us, a single development team was two engineers and one designer.

This categorization was important for the dev teams as well. The most important understanding for them was the commitment to macro deadlines. It's crucial to release macro projects on time because of all the external dependency placed on them.

Micros are the inverse. They are projects identified by the product owner (me) or other members of the development team. These projects are generally not roadmap items, but are commonly found in the backlog.

Micros follow a reactionary communication scheme. Proactive communication isn't as beneficial because usually the impact on the business team is minimal, so to communicate every little project to the same degree as macros would be highly distracting and inefficient.

I would generally push micro release notes to the business team around time of deployment. If the project was important enough, I would include extra documentation, like demos, but I never found enough net value in communicating more.

The business team would realize that all decisions—priority, design, scope, features, etc.—were made by me or the development team. They would trust our judgement. There would certainly be strategy in my micro decision making process, but it wouldn't be business-lead strategy like "We're pivoting from Market A to Market B next month."

The dev team would take on as many micros as it had capacity to tackle. Sometimes there would only be a handful as we juggled two macros; sometimes we would complete dozens of micros within a single release.

The benefit of micros to the dev team was the lack of external commitment on scope and timelines. If we felt it wasn't right to push an update, we would wait. This lack of commitment gave us hyper flexibility which undoubtedly lead to greater productivity output. I truly believe that letting the product owner and dev teams own the backlog produces both higher quality work and quicker releases.

Agile for Product Development not Product Management

The role of the Product Management, and one responsibility of the Product Owner, is to be super prepared. Planning and research are important!

Agile is not a framework for management. Be sure to separate your product responsibilities and realize that a large chunk of your duties comes before any development actually takes place. Those duties don't benefit from the rules of Agile.

It's About The "Package"

Product's impact on brand is mostly found through the experience customers have. Paying attention to all the little details is what separates the Apple's from the rest.

I've noticed a pattern with the products that I thoroughly enjoy: they have attention to detail on every moment of engagement. Even things as simple as resetting a password.

Part of the difficulty is finding the balance between the ROI of projects. Often those that make the overall experience better simply can't compete for attention. This is unfortunate. Good product managers will figure out how to make room. I don't have a good model to explain how to make room, I just know that those who make it happen are really good at their job.

Empathy Is Most Important

The most important tool designers can have is empathy, or the ability to understand one’s feelings to the same level as their own. On the surface, this may seem expected. It might also be mushy. But it’s more complex and important than indication would lead on.

First, lets talk about design. To design is to motivate. It is not to inspire. Art is the better career for changing an audience’s perspective. That doesn’t mean design can’t be inspiring. Plenty of designers are inspired by a fresh take on an old convention. But other designers are not necessarily the audience for our creation.

No, we motivate and persuade. We get people to click buttons, fill out forms, pull levers, write with pens. We persuade them to buy books, search for information, forward an email, push that shiny red button. Granted, not all design is meant to be so manipulative: thousands of designs go into engineering a car. But for the purposes of digital design, I believe our primary purpose is to convince our audience to do an action, whether it's commerce related or not.

In order to properly motivate, the designer must understand her audience. This is a known, generic observation. Everyone has heard of the cliché “put yourself in the user’s shoes” and so on. Although this is important, and I agree a requirement, it’s only a light descriptor for the root objective.

I’ve found that empathy is the foundational lens a designer must use. The main reasons:

Designers are the champions for empathy. Unfortunately, care like this gets a bad rap. Thus, empathy must be an organizational trait.

If engineers and developers don’t have empathy for the customer, corners will be cut and wrong approaches will be taken. After all, it’s much easier to not care about the users, even if you do have an understanding of what they want.

If marketing and sales do not have empathy for the customer, the wrong messages will be sold.

If management doesn’t have empathy for the customer, guidance will be misplaced. Focus will not be on the what really matters.

There is a difference between understanding the end user and genuinely caring about their experience with a product. If empathy isn’t present throughout the product’s provider, it shows.

Discussion

comments powered by Disqus