Managing a website or application #WYDK

Jordan Julien
Answers and Outcomes

--

If you know me, you know I’ve long considered websites and apps to be digital products; worthy of being managed by product managers. This is becoming reality in more and more organizations. I’m encountering more product managers in charge of websites and fewer brand managers; though, some websites are still viewed as a marketing communications channel. So, in this post — our final post in our “What you don’t know” series — I’ll speak to both marketing teams and product teams about managing websites.

Firstly, product managers & product teams

I’ll start by talking to the emerging standard; product teams. These teams are usually in-house teams; consisting of at least a product manager. However, some in-house teams are extremely robust; including project managers, business analysts, data scientists, experience designers, user researchers, graphic designers, art directors, writers, software engineers, solution architects, quality testers, and more. Regardless of how the in-house team is structured, the product manager plays a critical role: they decide how the website or application evolves over time.

Product managers can use internal resources if they exist, or they can supplement their in-house team with external resources. At Hostile Sheep, we’re often asked to plug-into in-house teams because they often have trouble finding and/or justifying a full-time user researcher or experience designer.

If you have a product team managing your websites and applications, you probably already have product visions that govern the various products you own. If not, creating and evolving product visions is an important first-step to ensuring organizational alignment with each product. Product vision documents usually include a crucial component we refer to as a product roadmap. This roadmap is usually closely managed by the product manager.

Developing a product vision is a unique, interdisciplinary, process that often involves an entire organization; from marketing to operations and finances. Hostile Sheep has participated-in (and led) several product vision workshops and processes. The most effective ones include all relevant stakeholders; including the c-suite. I’ll post a product vision deep-dive in a future post, but for this post, lets assume you’ve developed a product vision and are actively managing your product. These are the two processes for managing a digital product, using a product team:

Wireframes can be too prescriptive to enable teams to own UX decisions.
  • Define the product: this process is all about defining the product; what it looks like, how it functions, what content it includes, etc. The definition of the product changes as the product evolves. Release planning and a product roadmap helps define what the product looks like today, what it looked like historically, and what it will look like in the future. This process uses low-fidelity prototypes to define what the next release will look like. Much of the product team is continuously focused on fleshing out and deploying the next release.
A design system can enable teams to take ownership over UX decisions they make.
  • Enable the team: this process is all about enabling the interdisciplinary team; guidelines, governance, design systems. Releases, when using this process, are a little more flexible than the previous process. The product roadmap is usually a little different as well; it likely only has one or two releases planned, with a large feature backlog. The whole team uses guidelines to contribute to the continuous improvement of the product; which involves adding features/opportunities to the feature backlog. The product manager picks-and-chooses what features make it into the next (and subsequent) release. This process avoids prescriptive low-fidelity prototypes (that can occur when using the previous process) and prefers directional low-fidelity prototypes that are pattern (or component) based. The product team uses the low-fi prototypes to build pages or optimize existing components; empowering the whole team to make UX decisions.

At Hostile Sheep, we prefer to enable product teams; opposed to merely defining the next iteration of the product. Ultimately, we want our clients to manage their own digital products. We don’t think anyone is more qualified to manage our clients digital products than them. We’re always there to support our clients, but we’ve found that our clients WANT to have the tools to manage their own websites and apps, they just don’t have them. We provide our clients with the knowledge and frameworks; so they’re comfortable saying things like “This button is inconsistent with our other buttons.”, “We prefer using a dropdown list when users are choosing between 8–18 items.”, and “We use reductive filters, so we need to add an ‘all’ to that.”

We’ve encountered a number of shops that merely help their clients get to the next release of their product; while helpful, it’s the difference between “giving a man a fish” and “teaching him to fish”. There are lots of clients that just want to be given a fish, and that’s okay too. We’re also equipped to do that.

Secondly, brand managers & marcom teams

There are still some websites that are still managed by brand managers and marketing communications (marcom) teams. These are usually program-based websites and applications; sites and apps that were created to support a marketing “program”. For instance, Egg Farmers of Canada has a marketing program, that’s running right now, about eggs for dinner not being weird. If they made a website and an app that supports this campaign, those digital products would likely be managed by the marketing team.

Unlike product teams, marcom teams usually have less flexible timelines; often needing to launch a product (or products) in conjunction with a carefully choreographed marketing campaign. Because huge numbers of ad dollars may be driving users to a newly launched product; it’s important that these kinds of digital products launch on time — and include all the features users expect and need. That said, there are two ways to manage digital products when you’re part of a marcom team:

  • Set-and-forget: marketing campaigns are temporary by nature. As soon as a marketing campaign launches, its days are numbered. Since marketing campaigns can run for as little as a month or two, digital products that support marketing campaigns usually aren’t around long enough to employ continuous improvement principles. It’s enough to have a team available to deal with bugs or crashes. We don’t recommend thinking of products as being set-it-and-forget-it, except in the case of short-lived marketing products. Even in these cases, we still recommend measuring usage and take learnings into the next campaign. If products can be re-used between campaigns, that may be another way to extend the product lifecycle and improve the product with each new marketing campaign.
Campaign maps can be used to illustrate how a campaign evolves.
  • Campaign phases: some marketing campaigns include several phases that can span several months, or even a full year. Those campaigns that include a contest or game usually have multiple phases; as they need to announce the contest, get users to join the contest, judge the contest, announce the winners of the contest, and amplify the results of the contest. If an organization launches an app to support the contest, it will naturally need to be updated as the campaign moves from phase to phase. While these releases can be (and usually are) planned in advance; some level of continuous improvement can be implemented. Since, multiple releases will be planned; this provides an opportunity to measure and improve any issues.

At Hostile Sheep, we tend to avoid products that are created to support marketing campaigns. We prefer products that we can apply continuous improvement principles to. That said, we have helped clients build products to support particularly complicated marketing campaigns.

Conclusion

Websites and apps are either managed by a product team or a marcom team. It usually comes down to whether there’s a marketing campaign that the product needs to support or not. If a product’s being created for the purpose of supporting a marketing campaign, it’s likely to be managed by a marcom team. If the product isn’t being created to support a marketing campaign, it’s likely to be managed by a product team.

Marketing teams either launch a fully fleshed out product for the few months the marketing campaign is live for; or they launch a product that is updated as the marketing campaign moves from phase to phase.

Product teams either focus on building the next iteration of the product; or focus on establishing guidelines and governance to enable the team to improve the product long term.

It’s important to know what kind of product you have; it’ll help inform how the product will be managed.

This is our last post in the “What you don’t know” series. If you’ve gotten some value from our series let us know. We developed this series specifically for our client appreciation month 2020, but if we find that our friends, colleagues, clients and supporters got enough value — we may publish more throughout the year. So, let us know what posts you liked, what ones you didn’t — what you’d like us to share our thoughts on. Do you have questions we can answer? We’d love to hear your ideas.

--

--