2

The keys to a successful product knowledge transfer: part 2

 1 year ago
source link: https://www.mindtheproduct.com/the-keys-to-a-successful-product-knowledge-transfer-part-2/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

In part 1 of Luke Conley’s guest piece, he delved into the three keys to successful knowledge transfer. In this section, he offers an example of a knowledge transfer plan template — one you can copy and paste to send out today. Plus, we’ll examine three of the most popular knowledge base solutions, and how to get the most out of them.


Knowledge transfer plan template

To get you started, we created an open-endedknowledge transfer plan template as a simple TypeForm survey that you can copy and modify to suit your organization’s needs. This can be filled out asynchronously to collate the necessary information to get your org on solid footing.

Of course, ideally, you’ll be doing continuous knowledge transfer throughout the development process. The more connected your organization’s disparate domains of expertise are, the more you can leverage creative collaboration to strengthen bonds between departments and ideate collectively on solutions. In truly agile teams, you’ll have a constellation of experts, each a master of their own knowledge domain. It’s that symphonic thinking that enables teams of specialists to truly excel.

To get started with a more robust ongoing institutional knowledge-sharing approach, check out our review of the top knowledge-base technologies:

The top knowledge base technologies

Notion

Popular productivity software Notion has been on a tear for a number of years, amassing tens of millions of users and quite a bit of capital. Popular for its extensive number of templates and clever hotkeys, Notion offers a slick feel that’s boosted its appeal for both organizational and individual purposes. Let’s dig in.

We’ll start with some pros: first off, Notion’s UX is extremely fun to work in. The soft gray palette, the ease of templating, and the careful attention paid to aesthetics make writing a grocery list feel like planning the launch of the Apple II. That’s no small thing: anyone who’s stared at a company Wiki for a full eight hours will tell you a little polish wouldn’t be unwelcome.

Furthermore, Notion takes a kitchen sink approach to integrations, offering in-line code snippets, equations, user tags, even embedded Figma templates. If you’ve got the developer days, its API only makes its capabilities more robust.

That ease of use carries a subtle double-edge, in that it’s easy for things to get out of hand if disconnected ICs make rash contributions to the documentation without adhering to a sensible top-level format. Notion operates in a sort of tree structure, with top-level pages serving as “chapters” for different areas of the documentation, all accessible nested within one another in the lefthand nav. If you just start adding pages, things can get snarled. Search works well, but if you lack a comprehensive strategy, it can get overwhelming as docs grow.

Keys to success: Take stock of the various departmental interests your doc base is going to be representing, then establish a first pass at a knowledge base structure: for example, separate pages for marketing, product, and engineering, with clear sub-pages for the major areas of concern. Set expectations with everyone who will be touching the knowledge base about how to keep things sane and organized, and do a quarterly review of your department’s domain to make sure things are up-to-date, pruning outdated info, updating tool lists, and maintaining basic documentation hygiene. A half a day a few times per year will keep things organized and efficient.

Lastly, encourage people to make use of the “private” workspace for drafts, daily notes, and sketches, so the official knowledge base stays clean of abandoned pages and working documents.

Guru is an established player in the knowledge base space, especially popular with large organizations. The information takes the form of cards detailing institutional knowledge, best practices, and other need-to-know items. There’s a built-in verification system to make sure information is properly codified and up-to-date, and the system provides metrics to keep you on track for total accuracy.

Guru is more opinionated and structured than Notion about information layout: this makes it particularly effective for large organizations with coherent static processes around things like onboarding and compliance; you put something somewhere and it stays there, with explicit instructions for maintaining information fidelity. New users are greeted by a robust series of templates and prompts for baking out a knowledge base according to best practices. This thoughtful structure is a big help for tackling large knowledge-sharing needs in a coherent, organized way.

Keys to success: Get buy-in from your top-level stakeholders on the need-to-know information and bake out a strategy for verification. Guru encourages a centralized approach to knowledge management, so establish the core team for the initiative and get clear on responsibilities. This is a platform that rewards top-down organization.

Stack Overflow for Teams

The savior of developers from CS-100 students to principal engineers, Stack Overflow has been a tried-and-true source of engineering solutions for years. Now, they’re branching out into the organization-level space, offering their established core product on a per-team basis. Targeted specifically at engineering knowledge management, Stack Overflow for Teams establishes a community-knowledge knowledge base for your company’s specific use cases — VPN quirks, nagging problems with dev environments, and tricky gotchas with the deploy process. The familiar service offers low barrier to entry for teams that dislike being forced to adopt new tools, and the collaborative approach preserves institutional knowledge even when “the person who wrote that code doesn’t work here anymore.” The idea is to save time on engineering efforts where a problem is encountered once, documented, sourced, and solved, then the process is preserved for future engineers in similar trouble.

Keys to success: engineers prize efficiency, so whether you’re an IC developer pitching a new document base or a manager trying to improve processes, the easiest sell is how much time and effort this is going to save people. Every programmer knows the agony of the SO post that describes your exact problem, but got no resolution — posted six years ago. Ease of use goes a long way towards enacting change.

Wrapping up

Knowledge transfer can be a tricky process, and the ongoing challenge of managing institutional understanding offers unique complexities to consider. But with the right buy-in and some good old fashioned teamwork, the results can be transformative. Whether you’re sending off an outgoing teammate or building a second brain from the ground up, we hope this breakdown has been helpful. Good luck, and happy documenting.

There’s more where that came from! Access more great content on Mind the Product

pendo_mtp-ads_rise-of-prod-ops_footer-01@2x.png

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK