Where does in-app copy fit in your org? (Under Product Marketing, Design or other?)

The copy in the product itself is owned by our Product Design team. However, we have a Customer Engagement / Customer Lifecycle Marketing team that owns copy for in-app messages like tooltips, banners, carousels etc. PMM will also schedule in-app messages (depends on the message itself) where we will own the copy.

I know some orgs will have copywriters specifically for the product that will sit within the product or UX team, but I think this is more of a luxury at most organizations.

In my opinion, PMM has a better vantage of customer needs and command of customer voice to produce best in app copy, product naming nomenclature and in-product guidance. This responsibility can be shared with UX and PM to ensure everyone is on the same page. Engineering and PM usually need a lot of help in this department as it is not their forte. 

This is always a gray area :)

At Gong, most UX copy is owned by the product writing team, except for naming "Tier 1" products. Together with that team, we established a list of criteria that qualifies features or products as "Tier 1;" such as, the feature/product changes core product pillar messaging, or requires customer change management, or changes how we sell or demo the product. These are really dependent on your business.

For in-app cues (like announcement banners/modals, etc), we've established a RASCI model based on the objectives of the copy / in-app cue. I highly recommend starting here.

For example, if the objectives are awareness, monetization, activation, adoption—then PMM is the "Responsible/R," product design "Supports" on visual cues by handing the latest designs to the brand design team to stylize, PM is "Consulted," and product writing is "Informed."

When the objectives are to educate, support the UX, or onboard new users—then product writing is the "R," PMM is the "I."

Even this framework isn't perfect, but aligning on a RASCI for the various types of in-app copy/cues that exist is a very helpful first step.

For my company, it's currently shared between product, product marketing and design, but that's mostly a factor of being a startup and in the process of building out each of those functions. I think about it in two ways:

1. Is the in-app copy descriptive of the product itself? Things like feature names, onboarding wizard copy, CTAs make sense to cut across the three teams I mentioned, with product and design having a heavy say in those decisions.
2. Is the in-app copy meant to drive conversion activity / sales conversations? To me, this fits more with product marketing.

Ultimately your company's voice and brand should be consistent inside and out of product, so even if product marketing doesn't own it, I highly encourage being part of the approval process. 

In-app copy typically falls under Product Marketing. If it is something you do not own today, my advice would be to work with the Design/PM team who is currently owning this to understand how you can contribute/collaborate. For technical products, I often find PM/Engineering actually choose to own the copy. There may be some bias that they understand the customer better than you do. There is no rule for ownership but if it is something you want to do then I would talk to your extended team and show them why PMM owning in-app copy is the best plan for your business. Ensure you understand their concerns.

A few answers here, based on use case! 

Naming inside the product (like features, tabs, or experiences) would be handled by PMM during the launch process. PM is likely to have ideated an internally-referenced name early on, but as we get past the beta and understand what value users actually derive from the feature, PMM adjusts to better match what the user would expect to see, for the task they want to complete.

Other copy in the product UI that describes what a function is, or does, in the shortest and sharpest way, is handled by our design team (which sits inside our product org).

Copy that might show up under an information icon, or within an onboarding flow which explains the value of the feature, or how to use it to get the most out of your work, is written by PMM. Of course, now that we have a Growth PM, I suspect she'll focus on testing and tuning the language used in any part of an onboarding flow that would have material impact on customer activation. 

In-app copy does fit with Product Marketing - and Product! So technically, our PM team owns the in-product experience but PMM has full access to the tool. We have a slack channel for all in-app messaging and anyone who wants to do one posts in there following a format that says the purpose, how long it will run, to whom it will be shown, and a preview. Folks can ask questions, offer suggestions, and then we give the approval to set live. The results of these go into our quarterly retros. 

If it is on our website itself - we use a Drift bot. That mostly lives with our Demand Gen team but we have lots of access and support there - we are responsible for a lot of the copy on key, technical pages and again, we monitor that on a quarterly basis and report out. 

IME this should sit in engineering, but it's generally not a bad idea for the copy writer to solicit PMM feedback. PMM needs to be hyper focused on strategic tasks. This is a good example of a tactical distraction. 

If your company has the resources, I would advocate for there to be an in-app copy writer that sits under design. By putting them with design, they will have the shortest path to where the product is actually being made. That being said, they should be very aligned with both product management and product marketing. 

In one of my past roles, it's been a combination of product management and product marketing who were responsible for it. 

We like keeping this with the PMM or a Product Manager/Owner, as the person writing this copy needs to be super familiar with the product and user experience. They need to be power users, IMO. Occasionally, I've leveraged Support or Customer Success Managers for this as well, becausr they are so familiar with the ins and outs of the user experience.

Another solution would be to have someone is design or engineering draft the basic copy and have a copywriter make it sound better.