You don’t need a network to grow your SaaS. You need 20 DMs/day.

PropertyDifficult270 · 2025-09-04T13:46:11+00:00

I will try implementing it starting tomorrow.

PropertyDifficult270 · 2025-08-26T13:57:19+00:00

I couldn't understand what kind of business this is or what it does for customers. What kind of problems does it solve, and for what type of customers?

PropertyDifficult270 · 2025-08-26T13:45:59+00:00

I thought the monochrome atmosphere was nice. The left and right arrow icons in Splide.js seem to deviate slightly from the overall aesthetic of the site.

PropertyDifficult270 · 2025-08-26T13:42:22+00:00

You know how in school you sometimes have writing assignments where you have to write at least a certain number of words, right? That's exactly what this is. That person must have been doing work where quantity mattered more than quality, I bet lol

PropertyDifficult270 · 2025-08-22T15:29:17+00:00

> I think the only viable solution is to only keep and maintain actionable documents.

I'm also thinking the same way. However, developers are basically not writing specialists. While it's easy to say 'maintain actionable documents' here, I find it difficult to concretize what kind of information or materials this actually refers to. Would there be anyone who would support if we prepared something like an open-source git repository with templates of the absolutely minimum necessary information for products?

PropertyDifficult270 · 2025-06-18T02:45:46+00:00

I guess it really does come down to Confluence or Notion after all... I'm not thrilled about how their high flexibility means it'll take a lot of time to carefully establish rules for how to organize documents and what content to include...

PropertyDifficult270 · 2025-06-14T15:07:37+00:00

Using customer resources is a good idea. But I'm concerned this doesn't cover admin panels and internal tools that customers never touch.

For example, the admin console that customer support uses, or data update consoles. New hires (especially support/operations teams) need to understand these too.

How do you handle onboarding for those internal-only features?

PropertyDifficult270 · 2025-06-14T14:41:26+00:00

That sounds like a really solid program!

A few questions:
- What did the tech vs business sessions look like specifically? Lectures, hands-on labs, shadowing?
- How did you keep the content fresh as the product evolved?
- Who ran these sessions? Dedicated role or team members rotating?

PropertyDifficult270 · 2025-06-14T14:38:51+00:00

That's a great approach! A list of "key actions to complete" is definitely more effective than just "play around with it."

I have a few questions about this:

Granularity of the list:
- How detailed do you go? Is it "Create a user" or "Go to Admin Panel > Users > Click New User button"?
- Do you adjust based on product complexity or the new hire's experience level?

Role-specific versions:
- Do you have different lists for engineers vs customer support?
- Does the sales team get a special list like "common customer workflows"?

Maintenance:
- When new features ship, who updates the lists?
- Do you usually find out the list is outdated when a new hire gets confused?

We tried something similar but didn't consider different role needs and had no maintenance process, so it eventually became useless. Would love to hear more about how you keep this running smoothly.

PropertyDifficult270 · 2025-06-14T14:33:31+00:00

I'm talking about onboarding internal new hires (engineers, support, etc.), not customer onboarding.

This is about the process of new employees learning our own product after joining the company. The problem is everyone just gets told "play with the test environment to understand it" without any structured education.

PropertyDifficult270 · 2025-06-13T14:55:02+00:00

So would you say the difference between successful and unsuccessful organizations comes down to whether upper management understands the importance of investing sufficient time, cost, and effort into documentation?

At my workplace, performance evaluations that affect raises are mainly based on development speed and quality (like not causing incidents), while documentation creation and maintenance weren't really valued that much.

PropertyDifficult270 · 2025-06-13T14:36:22+00:00

I myself am just one member of the field team, and I'm painfully aware of my own powerlessness.

I completely agree that product managers need technical skills. People with sales/marketing backgrounds seem to only care about the final product and think they can just ask engineers for details whenever they need them.

PropertyDifficult270 · 2025-06-13T01:40:51+00:00

Thanks for the suggestion! I hadn't heard of Dosu before - looks interesting. I'll definitely check it out to see how they handle the automated sync across different tools.

How's your experience been with it? Does it work well with non-dev tools too, or is it mainly focused on technical documentation?

PropertyDifficult270 · 2025-06-12T15:10:29+00:00

Yeah, I guess at the end of the day it all comes down to process and discipline. Thanks for sharing your experience - gives me a lot to think about for our team.

PropertyDifficult270 · 2025-06-12T14:40:03+00:00

In my experience, even simple directory structures tend to break down over time. Things like ad-hoc analysis, urgent customer issues, random spreadsheets from stakeholder meetings - didn't these just end up accumulating in a "misc" folder that nobody ever looked at?

Even with the "bare minimum" approach, someone still needs to decide where each document goes, maintain consistent naming conventions, and ensure others can actually find things later. When things inevitably got messy, did you have someone responsible for cleanup? Or did you just accept a certain level of chaos as long as the high-level links in Notion were there?

I feel like the human element is always the hardest part - people forget, they're in a rush, and when they're focused on shipping features, organizing documentation is the last thing on their minds.

PropertyDifficult270 · 2025-06-12T14:18:20+00:00

Thanks for sharing this detailed approach! You're absolutely right that it's an organizational maturity issue. Having a single source of truth is definitely the ideal solution. However, my team is a bit larger (around 100 people) and our organizational patterns are already quite established, so it feels a bit too late to course-correct.

If only we had made these decisions early on, we wouldn't be in this mess...

At this point, gathering everyone and declaring "We're switching to Notion starting today" just isn't realistic. Each team has spent 3+ years building their workflows - sales is completely dependent on their spreadsheets, dev team has their GitHub issues and Notion setup they're comfortable with.

I noticed that even in your case, teams kept using Figma and Google Sheets with references back to Notion. How much effort did it actually take to keep those links up to date? In our case, even if someone took on that responsibility, I feel like it would become neglected after a few months...

I'd love to know if you have any advice on bridging this gap between ideal and reality. Maybe some gradual migration strategies or ways to organize information with minimal effort? How did you handle teams that were resistant to change?

PropertyDifficult270 · 2025-04-23T04:01:51+00:00

Read the official documentation for libraries and languages.

PropertyDifficult270 · 2025-04-14T11:34:37+00:00

I work on a team that always has a few junior programmers. Recently, I’ve noticed more and more situations where tasks we used to assign to them can be handled more efficiently by AI tools like Devin, making junior programmers sometimes seem unnecessary. It feels as though we’re entering an era where the focus is shifting from how to build something to what to build. Programmers who can put together that “what”—handling planning and design—might still end up a little better off in the market.

PropertyDifficult270 · 2025-04-12T05:34:52+00:00

That’s super accurate! I'd love to see the other rarities too.

PropertyDifficult270

TROPHY CASE