How to think like a product team (even if you aren’t one)

You may be part of a product team and not even know it. Not every product team creates and manages something that’s sold to customers. Maybe your team launched a financial wellness application for the website or provides a self-service portal for customer support—you may not think of these as products, but they are best managed that way. So, if you’re, by default, part of a product team, you want to think and work like one! Otherwise, you’re in for some serious frustration.

7 Strategies for working like a product team

At Think Company, we’ve worked with many organizations to help them create processes and team structures to ensure they work effectively like a product team. We’re sharing strategies that can help improve the way you work, ultimately improving your products and services. Let’s dive in.

1. Structure is critical

If your organization doesn’t have a product team structure, likely there are no product owners within the organization. This can create confusion over sign-off for product updates and, sometimes, even for the initial launch. Without a product team structure, the product is often neglected and can become stale. If no one is taking the lead or directing the product vision, you won’t get far in improvement projects. 

Customer needs and expectations change over time and so should the product. Development should be iterative and ongoing—modern products are not “set it and forget it” endeavors. Save those for your slow cooker.

2. Too many cooks spoil the broth; create a communication plan

Another issue is poor (or no) communication across teams. Likely, your digital product (we’ll go ahead and call it that) has many different stakeholders across different teams and departments. If you’ve got a self-service HR portal, for example, you’ll likely have stakeholders outside of HR: finance, IT, the web team, and more. Without a product team structure, communication about next steps and the creation of a shared vision is often challenging, especially in organizations that are highly siloed. In many cases, the loudest voice gets their way, and that’s a predictable way to produce a poor product.

Include the right people and have the right conversations

And speaking of multiple stakeholders, IT and development resources are a very important voice and one that’s always a part of any digital product. These people and their skills are precious and often scarce within organizations. Without a product approach, there’s no plan for engineering and development, so these resources don’t get allocated to the product.

Without adequate technical resources, your team may lack the expertise to implement the features you desire, and the design will need to be significantly changed. And even those features you can implement may be clunky and unreliable. Over time, this creates more technical debt. If you do eventually obtain the resources you need, they’ll likely need to spend quite a bit of time fixing past problems instead of developing future-forward solutions.  

Finally, without a team mentality, the organization will have, at best, a fragmented understanding of the product landscape. Knowing your end-users’ needs isn’t enough. Every organization exists within a competitive landscape, and it’s vital that your product keeps up and stands out against competitors, even if it’s internally focused. After all, your organization competes for talent—you don’t want frustration around the internal tools and products your colleagues use because they’re outdated and hard to use. 

3. Start with the goal, not the product

The first step to thinking like a product team is to establish a product “owner” who can provide sign-off for releasing new features, developing new features, and, if you’re still in the initial development phase, the product launch itself. If assigning a product owner isn’t practical for whatever reason (though we highly recommend doing so), at the very least, assign a gatekeeper to interface with other stakeholders and third-party developers. There has to be a central point of contact for all things product or nothing will get done. 

Also, while it may sound counterintuitive, it’s important for a product team to NOT start improvements or building by thinking of the product. Begin with the goal—that means understanding the customer problem you’re trying to solve. 

4. Make sure you’re building the right thing; maybe you don’t need a chatbot

For example, here at Think Company, we worked with a client who came to us to develop a chatbot that would help healthcare providers (HCPs) answer questions they had about prescribing our client’s medication. But, once our team started user research (IDIs, contextual inquiries, etc.) and began talking with HCPs, it became clear that a chatbot wouldn’t solve the problem. HCPs pointed out that getting information on the medication was difficult because there was not an established medical portal. Instead, we implemented a searchable wiki that employed natural language search, which was a more appropriate, more cost-effective solution.

We looked at our client’s goals, took a step back, talked with the customers, and ensured that we were building the right solution, not based on assumptions. 

5. Gut feeling and personal experience aren’t enough; invest in research

Understanding your customer’s needs isn’t a simple task. We are constantly talking with end-users as part of our process and are always surprised by what we discover. Often, customers aren’t fully aware of what they need from a product. That’s why it’s so important to invest in well-designed research to tease out the needs that customers may not even be aware they have. 

Research can also help you better position the product in its current and future form so that it’s well differentiated from competitors. 

6. Set the right scope

Next, set an appropriate scope, beginning with a minimally viable product (MVP), and make a plan to augment it over time. Setting the bar too high initially with all the bells and whistles you eventually want to see will delay development significantly, increase the chance of bugs, and harm morale. Keep it simple. Create a working product that achieves your core goals and build from there. 

You want to separate the roles of product management and solutioning. For example, the development team should not also manage the product, because implementing features and crushing bugs can create a kind of tunnel vision that makes it difficult to see the larger picture. There needs to be someone or a team of people whose job is to set the vision for the product and ensure that any work done is working towards that vision.

7. Get an outside perspective

Speaking of perspective, sometimes it’s a good idea to bring in an outside expert with design expertise, especially if you don’t have a product team in place. Ideally, you want a skilled, experienced third party that can help build the internal product team and provide everything required to do so in the meantime.

Once your team is ready to go, the third party can disengage, having done its job teaching your team how to fish and not simply giving you filet after filet—because that’s awfully expensive—both metaphorically speaking and in product development. 

If it has end-users, it’s a product. Manage it like one

The bottom line is this: If you have a portal, an app, or any kind of digital functionality your organization wants to release or has already—regardless of whether end users are internal employees, partners, or customers—you’re managing a product. And the most effective way to manage a product is to think like a product team, even if you don’t think of yourselves as one.

Are you looking to improve your team structure and start managing your digital solutions like a product? Our team of experts can help!