From Atoms to Pixels: Digital Product and Manufacturing

From Atoms to Pixels: Digital Product and Manufacturing

From Atoms to Pixels: Digital Product and Manufacturing

Written by
On

This is the fifth in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.

At first glance, software companies and manufacturing companies seem diametrically opposed: pixels vs atoms, machine learning vs. machines, bits and bytes vs. nuts and bolts.

Modern product management nerds like me spend a lot of time with companies and teams whose primary output is digital, comprising data and experiences that use computing technology and software engineering techniques to enable users to interact through websites, installed software, or mobile apps. It’s a discipline combining the best parts of user experience design, marketing, business strategy, and software development and delivery.

Meanwhile, manufacturers of physical products are engaged in their own professional domains — and, by the way, manufacturing contributes about 2.3 trillion dollars to the US GDP each year. These businesses have deep expertise in materials, chemistry, physics, manufacturability, supply chains, operations, safety, and logistics, things many digital product companies aren’t particularly concerned with. At first glance, these manufacturers might not seem too concerned with the processes of UX design and agile software development

But that’s at first glance.

A False Binary

Take another look, and you realize that this binary division between software and manufacturing companies, like so many binary divisions (IT vs. the business, STEM vs. the humanities, rock n’ roll vs. country) is false. It obscures and limits rather than clarifies and enhances. 

The truth is the modern manufacturing company is, in many cases, an honest to goodness software company too, just as much as the hottest consumer internet brand. These manufacturing companies use software throughout their businesses, both for internal operations and for interacting with customers through marketing, commerce, service, configuration, and distribution.

The archetypical lifecycle of such a company looks like this. They started many years ago, became successful at building and selling physical products in a specific market (dog food, brake pads, microwave ovens), and perhaps expanded into adjacent markets. At some point, perhaps in the 1970s or 80s, they started using software internally to manage operations and facilitate decision making. Finally, perhaps relatively recently, they turned that software outward, using the Web and mobile apps to satisfy and delight customers. And so now, they are both a manufacturing company and a software company — even if in some cases, they don’t even realize it. This is what Marc Andreesen meant when he said, famously, “software is eating the world.” 

Here’s an example: A few years ago, I led digital product and UX for a venerable provider of yearbooks, class rings, and other manufactured products for celebrating scholastic achievements. That company has outstanding manufacturing facilities and processes. They operate huge plants where they print millions upon millions of yearbook pages. At other facilities they use sophisticated custom engineering and precision manufacturing to make one-of-a-kind pieces of commemorative jewelry.

But we also designed and built some interesting and impressive digital experiences that were part of the product experience. High school yearbook editors, designers, and photographers used our custom-built web-based publishing tools and mobile apps to collect memories of a school year and to design great pages and book covers. That one-of-a-kind ring that commemorates a student’s school experience or championship crown? It was designed through an app, rendered in 3D, purchased through e-commerce and shared on social media before it ever became a physical object. And that software is a product provided by this company as much as the ring itself is. 

So is that company a manufacturing company? Yes, absolutely.

Is it a software company? Yes, absolutely.

The truth is the modern manufacturing company is, in many cases, an honest to goodness software company too, just as much as the hottest consumer internet brand.

Tips for manufacturers adopting a digital product mindset

Because a manufacturing company is a software company, too, it stands to reason that the manufacturing company that wants to differentiate can do so by strengthening its digital product capabilities. If you’re a manufacturer interested in adopting the techniques, teams, and processes of consumer Web-based technology, consider the following:

  • Start with the story of your customers. Think creatively and expansively about their needs. Then, focus on meeting their needs through a combination of digital and physical interventions. Say you manufacture dog food. Dog food customers don’t just need tasty kibble to fill their pooches’ bowls; they need to care for their dogs’ nutritional needs. You, a dog food maker, might find opportunities to win new customers and surpass your competition if you can uncover software-enabled ways to address these needs. In addition to providing food, can you also help with feeding schedules, hunger alerts (app name: Pavlov!), delivery of heavy bags, analysis of pet health?
  • Introduce your manufacturing and software teams to each other. One easy tip: make sure your software teams and your manufacturing teams get to know each other. They’ll learn a lot from each other, and both teams’ work will improve. In addition to getting out of the building (“GOOBing”) to spend time with customers, your software product teams should pay a visit to your manufacturing facilities, too. 
  • Focus on iterative discovery before concerning yourself with efficiency and scale. Manufacturing operations pros are excellent at designing processes to efficiently produce high-quality goods at scale. But if you are developing digital products, you should experiment and validate (and possibly disregard or change course) before you try to scale up a new product or process. Steve Blank, a software startup guru, says that the greatest risk to a tech business is premature scaling. That’s true for manufacturing companies developing their software product expertise, too. Instead, squeeze out inefficiencies after you’ve achieved product-market fit.
  • Understand where software and physical products differ. One example: in software, a small but meaningful error in text can be repaired with just a few keystrokes and a push to production. But if that same error is included in, say, printed packaging, the cost of correcting it after the fact can be substantial. Investment in QA processes could therefore vary widely between software and manufacturing teams. Other areas where manufacturing models and software models differ significantly: mass customization, globalization, distribution, and upgrades and improvements.
  • Consider new business models. Could a lawnmower company include subscriptions to insights about grass cutting? Could a birdfeeder-maker pair with advertising driven content about our feathered friends? Subscriptions, advertising, upsells, personalization, premium memberships, e-learning: these are just some of the core models of technology product firms. They could apply to you, too.
  • Hire and organize staff with the specialized skillsets of software products. As they build their software product capabilities, manufacturers may need user experience designers, data scientists, software developers, content writers and producers, and digital product managers. Depending on your organizational dynamics, consider separating your digital product function from the IT function, to give your digital product leaders their own seat at the leadership table. Or think of it this way: Google has a world-class IT department, but its IT department doesn’t build Google’s software products (search, maps, docs, etc.) Similarly, in many cases a manufacturer’s software products may be best handled by a dedicated product function outside the IT department. 
  • Manage your digital initiatives with product measurements. You may be inclined to think that your physical goods are your products, while the digital stuff is another IT project, much like your ERP upgrade or the new email server. These projects’ success is typically measured by delivery dates, resources, and budgets. These are important, but they’re internal metrics. Your product makers and leaders need to be concerned with business metrics: customer acquisition, retention, satisfaction, competitive differentiation.
  • Adopt a product mindset for your software. With our customers, we use the term product mindset as our shorthand for the set of attitudes, beliefs, tools, and processes that produce great products. The essential elements of this mindset: Listen to your users. Delight through experience. Deliver often, even relentlessly. Shift requirements as you learn more. Adapt and learn, rather than gate and stage. Recognize that while successful projects end, successful products endure. 

Manufacturers aren’t going anywhere. As long as humans live in a world where physical goods contribute to our comfort, well-being, mobility, and economic viability, we’ll always use and appreciate things that are made. But the line between the virtual and the physical, the pixels and the atoms is getting blurrier every day. If you’re a manufacturing company, remember that you’re probably also a software company. So you might as well start acting like one.

Image Credits:

Industrial Drill photo by Greg Rosenke on Unsplash
Women working in manufacturing facility photo by Remy Gieling on Unsplash
Wind Turbine plant photo by Science in HD on Unsplash

 

The Product Mindset: Let Them Eat Cake

The Product Mindset: Let Them Eat Cake

The Product Mindset: Let Them Eat Cake

Written by
On
For a clue about what a company or team (or a person or nation) values, just look at what it celebrates. After all, we celebrate things we’re proud of or things that are meaningful to us.

If you work in business or technology, you’re likely familiar with the rituals of celebrations in a workplace: donuts in the breakroom, a leader’s words of commendation, some small talk and standing around. In fact, the popular TV show The Office had a long-running gag about employees maneuvering for control of the Scranton branch’s influential Party Planning Committee. That joke wouldn’t have worked if we didn’t understand office celebrations.

While our time in offices has been sorely limited in recent months (Thanks, COVID!), think back to those workplace celebrations. What events do you celebrate in the office? Probably personnel moves like new hires, departures, and promotions, yes. Maybe a few personal events, like baby showers or significant birthdays.

But I’m guessing your workplace also celebrates major achievements in projects. The upgrade was finished, you shipped the release, the milestone was reached. So someone brought in a big box of bagels or picked up artisnal donuts at a hipster bakery. Maybe you all took off early and enjoyed a happy hour at a local tavern. Project managers and teams are well-conditioned to celebrate these project milestones. “Let’s all have cake in the break room!” “Why?” “Because the thing we were doing is done!”

Don’t just celebrate project achievements

Now, I’m not here to denigrate donuts, taverns, or cake. (Although, watch the carbs, people!) And celebrating achievements can certainly help a team’s motivation and cohesion. But when you celebrate the tasks you’ve completed or dates you’ve hit, you’re ignoring the real indicators of product excellence: user needs you’ve met, markets you’ve expanded, things you’ve learned, success you’ve built. A cake to honor a thing finished on time and on budget is a ritual of a project.
Projects are a great way to organize resources or manage and sequence labor. I’ve known many wonderful project managers and benefitted from great project tools and resources.  But a project’s primary concern is inward: deliverables, schedule, budget. Customers don’t really care about the way we organize resources or manage and sequence labor. Our work breakdown structure is of little concern to the user. They are not delighted when your actuals matched your estimates. In too many cases, customers don’t even care about your project’s requirements, a nominee for the strangest word in tech.
The uncomfortable truth: that artisnal donut with the real maple frosting might just be celebrating the wrong thing done well. So I prefer celebrating product successes. A product mindset, or a product orientation, looks differently at work worthy of celebration. While projects are a way of organizing labor & resources, product is primarily concerned with delivering meaningful responses to satisfy the needs of your users, and therefore with generating value that endures. And so teams with a product mindset celebrate progress towards that value.
The uncomfortable truth: that artisnal donut with the real maple frosting might just be celebrating the wrong thing done well.

Celebrating product success

With that in mind, try adding new rituals to your workplace celebrations. Here are some other things a product team might commemorate:

  • Something you learned. If you’ve uncovered meaningful new information about a market, or even learned something about your teammates that will help you work together, you’ve made progress towards a valuable product. That’s worth celebrating.
  • A change in your requirements or plans. This may sound crazy to project leaders, but a changed requirement usually means you know more about what your customer wants. And that’s worth celebrating.
  • New insights from customers. Did you visit a customer site? Did you bring users in and get their insights on your prototype? If so, you’ve likely learned something about your value hypothesis. And that’s worth celebrating.
  • A customer outcome. This is a big one. If your product solved a problem for a cohort of customers or improved the value exchanged between your business and your users, then the product is performing its essential role as a vehicle of value. And that’s worth celebrating.
  • Business milestones traced to product work. If you’ve crossed a threshold in customer satisfaction (“First month ever with more customers using the self-service online product than called the tech support hotline”) or sales and revenue (“Over $10 million in the product’s subscription sales in Q3”), and you can see how your product drove that achievement, well, that’s worth celebrating.

So yes, happy hours and cake in the breakroom are great little rituals of our professional lives. And donuts are undeniably delicious. But the next time you’re planning a team-building celebration, ask yourself, “Are we celebrating mere output, or meaningful outcomes?”  

Sparkling Cupcakes for a work celebration

The Product Mindset: Your Secret Weapon is Value

The Product Mindset: Your Secret Weapon is Value

The Product Mindset: Your Secret Weapon is Value

Written by
On

This is the third in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.

As we’ve explored throughout this series, a surefire way for companies and teams to improve their value to their customers and align their own priorities, mission, and working cadences is to cultivate a product mindset.

This is the set of attitudes, beliefs, and behaviors that is concerned with building your business by building great products in response to the needs and desires of your customers or other users. A product mindset prioritizes outcomes, learning, understanding of users, and total system health. It’s an approach that pairs neatly with agile development models.

My SDG colleagues and I have had the pleasure and responsibility of working with teams and customers across industries and contexts. One observation I’ve made is that working teams at the ground level are generally willing to try new methods and approaches, like a product mindset.

But even the most willing and progressive team may be fighting hidden forces. These forces can hinder good product practices for even the most collaborative and productive product team. In effect, the team is paddling against a current, and it may not even know it.

The hidden, internal forces

It looks like this: teams of engineers, product managers, and designers might be excited about product-led, customer-centered, learning-driven approaches. They are happily collaborating to shape a compelling vision, break that into its key themes, align discovery and development work to those themes, and build a measurement framework that connects their daily work to their business performance. They’re excited to pursue value and satisfy their users.

And yet, someone on the team, maybe a scrum master or a mid-level product manager, will utter sentences like: “uh, no, I don’t think we can prioritize that valuable thing, we are committed to this other thing instead” or “we’ll never get that approved ahead of this.” It’s as if something is keeping them from working in the productive, customer-driven, agile way that they want to work.

In my experience, more often than not, the problem they’re running into is at the uppermost levels of approval and investment within their own organization.

To understand this, consider the way many companies govern the work of their technology teams. Usually, there are executive systems that control which technology projects are even started. These processes often happen at annual planning and budgeting levels, on relatively long (quarters to years) cycles. They look like an estimating, budgeting, prioritization, and approval exercise, all designed to ensure the right work gets funded. Requirements, estimates, and rationale are made into a business case, complete with costs, usually by a sponsoring executive. And then a leadership team decides which costs are worth incurring. The decisions are based on estimated return on investment (ROI), and on which sponsor makes the most compelling case.

If the work is approved, the product team is then on the hook to deliver the thing it promised during this funding and approval cycle. But some people on the team may not even realize this origin story, and the obligations this system puts on the product team.

When working with executive sponsors who might be gathering information for planning & funding processes, don’t focus on the things you’ll make. Instead, focus the conversation on value you’ll produce.

Change the conversation to value

To be clear: no one running these budgeting and planning processes wants to hamper a team’s ability to deliver value. Usually, these systems involve astute leaders, often at the helm of the organization, who are charged with ensuring the overall success of the company. I have no doubt that they want to make good choices. But they may have backgrounds and motivations that emphasize certainty over a product-driven, learning-driven attitude. Such leaders can be instrumental in helping a product team succeed, but they also need to manage a whole host of executive concerns, like investors, sales performance, regulatory affairs, PR, competitive threats, which aren’t necessarily amenable to your product mindset.

And that’s OK. As a product leader, you’ll do well to recognize this dynamic, and to navigate it with maturity, clarity, and communication.

Our best suggestion: when working with executive sponsors who might be gathering information for these planning & funding processes, don’t focus on the things you’ll make. Instead, focus the conversation on value you’ll produce. Here are some specific techniques.

  • Involve leaders in developing a well-articulated product vision and value proposition. Share your vision early. In fact, ask your leaders to help. Many executive leaders are quite skilled at writing vision statements and articulating value propositions, and their vision will be instrumental in the success of the product. Then use their vision to shape the deeper work of the product team. By doing so, it’ll be easier to explain your choices and recommendations upward, since the leaders already have the context of the value proposition.
  • Design and track metrics tied to your vision’s themes. Ask executives: what customer behavior or metric would make you feel good about our technology products? Then, connect your product work to those metrics. Don’t fixate on “building a portal”; prioritize “improved customer engagement,” for example. The portal might be just one way to do this. By doing this, you’ll move beyond questions about feature delivery to conversations about the value of those features.
  • Reinforce your product-driven approach. Explain how you’ll drive those metrics through relentless discovery of functionality and experience. Reframe their desire for certainty about deliverables with a focus on uncovering what’s meaningful to customers and the business. In such a dynamic, the teams — not the executives — are then responsible for producing value through functionality and for reporting back results.  Explain that effective teams might run multiple experiments, shut down things that don’t appear promising, accelerate things that do.
  • Celebrate small successes. In some organizations, becoming product-led may take years of work and change. Don’t get discouraged if all you’re able to do during this cycle is, for example, get the IT delivery manager to build time for discovery into the project plan. That’s progress!
  • Commit to clear communication. Above all, promise your leaders that you’ll regularly report on the results you’ve achieved, in the language of the metrics you’ve prioritized and the value proposition you’ve agreed to. Then, keep that promise.

One last thing — and this might be a bit dangerous. Even if your company’s annual planning cycles seem committed to prioritizing and approving certain projects, with specific deliverables, remember that these projects usually aren’t what your senior leaders really want. They want the outcomes represented by those projects: revenue, growth, satisfied customers, competitive differentiation. They want value.

So even if they have approved and funded a project or a feature — say, “build a new portal site for managers” — what they really want is the outcome, the value that the feature expressed. If you can translate those items to value,  you may be able to get away with delivering something else, like, in this example, creating a new manager view for an existing site.

With good communication, and perhaps a bit of charm (one of the most important soft skills of a product leader), you’ll satisfy your leadership, start paddling with the current — and, more importantly, delight your users and build a great product.

Photo credits:

Kayak paddling upstream photo by Tim Foster on Unsplash
Opening door photo by Jan Tinneberg on Unsplash

The Product Mindset

insights

The Product Mindset: It’s Your Users’ Product

insights

SDG Consultant Co-authors North Star Playbook

insights

The Product Mindset: It’s Your Users’ Product

The Product Mindset: It’s Your Users’ Product

Insight

The Product Mindset: It’s Your Users’ Product

Written by
On

This is the second in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.

Several years ago, one or another of my daughters (I have three) said, “Whoa. Dad has an Instagram?”

First of all, my Instagram account is utterly unremarkable. I mostly use it to look at interesting art and photography to soothe my weary soul. My digital media consumption is not the point of this story.

Now, what struck me about my daughter’s statement was the relationship it proposed between me and the product: “Dad has the product.” Not “Dad occasionally engages with the features of this product.” Not “Dad maintains an account on an application provided by a company.” In Dad has an Instagram, my daughter proposed a more substantial relationship between the product and its user. The product, in this wise formulation, belongs to its users. My daughter, then a preteen, understood this instinctively. 

So often, we product managers, product designers, and product makers think primarily about our own relationship to the product. What should we build next? Can we fit this in the next release? Sales wants a feature: can we promise it? All of those questions put us, the team of people making the product, at the center. But that’s not where we belong. “Dad has an instagram” reminds us that the relationship between a product and its maker is only meaningful if we understand and prioritize the relationship between a product and its user.

The most powerful tool in your toolkit

The product and experience design community has developed many powerful tools and methods to help product managers, designers, and makers. At SDG, our product strategists use the Kano model, relative value, North Star Framework, theme-based roadmaps, and opportunity/solution mapping. We visualize these with grids, Venn diagrams, 4-blocks, 9-blocks, and swim lanes. Our user experience designers and researchers build user personas, craft journey maps, and make mockups, wireframes, and prototypes. 

But of all these tools and methods available to product teams, the most powerful is getting to know the people who use your product. The product — as my daughter observed — is theirs, even more than it’s yours. So spend time observing them, talking with them, listening to them. I’d get rid of every chart and model and software tool in my product kit before I’d get rid of time spent with users.

But of all these tools and methods available to product teams, the most powerful is getting to know the people who use your product.

How to get to know your users

Here are some tips to help you get to know your users.

1. Understand your users’ context.
Most software products are made in a similar physical environment, usually an office building with desks and coffee and decent lighting and nice double monitors (or, in these COVID times, in home offices). But much software is not used in such an environment. Users may be outdoors, under pressure, available only in brief bursts. Software used in, say, a pediatric dental office might be used with rubber gloves while a worried child weeps nearby. Software used in an industrial setting may have thunderous machines in the background and only be available between shifts. Pay attention to how they actually use the product, even if it’s not how you think they should be using it. You’ll learn a great deal if you Get Out of the Building into the wild, where your users are. Product folks have even developed an acronym for this behavior: GOOBing.

2. Understand your users’ stories.
Your users are engaging with your product for a reason: to help them with their work, to increase their understanding, to ease transactions, to improve their lives. You’ll make better choices and thus better products if you know their stories. For example, a medtech product might be used by people with a history of health concerns, who are feeling fear, uncertainty, and anxiety. You should respond to them differently than you would on a product used to help an eager bride and groom plan their wedding. Understanding the stories of people — needs and desires, frustrations and fears — will help you with priorities, user flow, layout, interface text, and navigation.

This understanding of users’ stories in order to understand needs and potential responses is where product management and product design converge. A marketer or business manager may get involved in product work to address business and market opportunities. An interaction designer may get involved in product work to tackle human factor and interaction challenges. But both are concerned with the story of the product’s users. This is why we believe that product designers and even playwrights and poets make great product managers, researchers, or analysts. Product work can learn much from disciplines like anthropology or even fine arts: don’t overlook such skills as you build your team.

3. Involve your whole team.
Empowered, cross-functional teams make the greatest products. But many product teams rely on one or two people to understand the users, while the bulk of the team simply takes direction from those emissaries. For example, it’s commonplace for a business to think that the designer on the team should handle user research on her own, and to worry that including developers in these activities is a waste of time and money.

I’ve found that everyone benefits from time spent with users. Engineers who witness the frustrations a user has with the product they’ve made will understand the issue more completely than one who is just responding to JIRA tickets. So include the whole team in the field trip to a user site, or at the very least organize a viewing party where the whole team can watch the recordings of research sessions. Rather than being an inefficient use of expensive developer time, it’s the quickest way to build empathy and understanding. It will pay for itself many times over.

I can honestly say that in my 25 years or so working on digital product, I’ve never had a single conversation with a user that felt like a waste of time. Every conversation, every observation is time well spent. So if you want to supercharge your product mindset, get up from your desk, shut down your laptop, and get out into the wild, where your users roam. 

Photo credits:
Conversation and coffee by Priscilla Du Preez on Unsplash
Engineer Photo by ThisisEngineering RAEng on Unsplash

The Product Mindset

The Product Mindset

Insight

The Product Mindset

Written by
On
Product is enjoying a moment. Twenty years ago, when I first landed a job with the title of “Product manager, interactive media,” not many people even knew what the job was. (Confession: I may not have even known what the job was!). Now every smart company is building up teams of product pros, and product manager was ranked 4th on Glassdoor’s recent list of 10 Best Jobs in America. The reason for the rise of product management is clear: product skills help companies satisfy customers, win markets, and build their business.

Consultants and bloggers (yeah, I’m both) have sprung up to help leaders and teams get better at “doing product.” We product folks often talk about “having a product orientation,” “becoming product-led,” or “adopting the product mindset” — but to do that, you first need to understand what a product even is.

Product, defined

Let’s start by defining product. I define it broadly:

A product is a response to a human need or desire that confers benefit to both the recipient and the provider of the response.

So if a company makes a thing that satisfies a person’s need, and the person is willing to do something that benefits the company, like give them money, well, that thing is a product. In some cases, the product is obvious. I need to open a can of soup, the Acme Can Opener Company makes a device that does just that, so I pay Acme for its can opener, its product.  The product is what connects Acme’s mission — “we shall leave no can unopened” — to their customers’ need — “I’d like some soup, but gosh darn it, it’s sealed up in this can.”

Software, including websites and mobile apps, complicates this a bit. In a world where every type of interaction, from banking to dating, is intermediated by software, human needs and desires are often best met by a digital experience — so those digital experiences are products too, just like the physical items are.

As a thought experiment, imagine other human needs that the Acme Can Opener Company might identify and respond to. 

Category User need or desire Response that meets that need or desire — in other words, a product
Commerce “I need to buy a can opener.” E-commerce website
Service “I need to repair my can opener.” Customer support knowledgebase, repair services, scheduling tools
Business-to-business “I’m a can opener dealer. I need to maintain my inventory.” Portals and other systems for B2B users
Customization and configuration “I’d like to monogram my can opener.” Customization app integrated with manufacturing systems
Community “I’d enjoy meeting other can opening enthusiasts.” Forums, personal profiles, messaging, networking tools

All of the systems and experiences that address these needs, solve these problems, or satisfy these desires are products, as much as the can opener itself is. And they require vision, planning, execution, and sustenance: all of it is product work, done by product managers and product teams.

In a world where every type of interaction is intermediated by software, human needs and desires are often met by a digital experience — so those digital experiences are products too, just like the physical items are.

Product as a mindset

Once we understand product, it’s easier to understand the product mindset. It’s an organization’s behaviors and structures that are oriented towards making, delivering, and supporting great products — which again, are responses to the needs of humans.

Here’s an list of some of the most important of these behaviors and structures.

  • A near obsession with understanding the people who use your products
  • Empathetically listening to and observing the behaviors and needs of customers​
  • Relentlessly delivering value​
  • Celebrating impact over celebrating output
  • Designing to solve problems​, not just as decoration
  • Accountabity to business goals​, even more than project plans
  • Organizing in cross-functional, relatively autonomous teams
  • Embracing, rather than resisting, change​

This mindset can supercharge business success. When you and your team adopt a product mindset, your priorities become clearer. Your organization understands its customers. You become more observant. You become more innovative. You become more aligned as a team. People become more satisfied. 

Building this product mindset isn’t easy — what is? — but it’s the hallmark of many great products and teams. Do this, and the world will be your oyster. Oh, and those oysters come in a can.

Can Opener The Product Mindset

Photo credits:

Rock cairn photo by Sean Stratton on Unsplash
Tablet photo by Leon Seibert on Unsplash

Read more