Tag: ai

  • In Pursuit of Clarity of Thought

    Recently, I have found myself feeling nostalgic for P2. P2 is a tool crafted by a previous employer that allowed documentation and communication across teams. The micro-blogging product allowed long form discussion to happen by being easy to use, having tags for individuals, a robust notification system, and making most things searchable. It was a verb as much as a product. The company culture was embedded with it, to the point that “If it isn’t in P2, it doesn’t exist”.

    As someone who has kept a journal for more of my life than not, writing out my thoughts has always been a way to process what is happening and next steps. Aside from the in-the-moment-brain-dump benefit, these writings have acted as record keepers. I can piece together how I got where I am today by seeing where I was before. Oftentimes, passing of time and new experience allow me to look back at an earlier period of my life with a different insight. Patterns and issues I was blind to become illuminated with a reflective perspective.

    Currently, my day-to-day work is heavy in interaction with LLMs. It feels like I am writing more than ever. At the same time, it seems easy to lose the context thread. I keep finding myself wishing for a place to look back, a desire to just “P2”.

    When I stopped to examine why, more than a year later, I still feel the loss of this tool, I realized it was more about a practice than it was about the tool.

    Long form writing forces clarity of thought.

    My opinion is that LLM’s encourage brevity. The harnesses and UIs that allow us to interact have short message boxes. The prompting and direction are meant to be a conversation. The models themselves do better with specificity over vagueness.

    P2, blogging, and journaling all force me to stop and think long enough to create a fully fleshed out piece of prose. This pausing, writing, and editing cycle creates a more distinct picture not only for the reader, but in my own mind. The action of fully describing a problem can often illuminate its solution, often called rubber-ducking in the tech world. And, of course, there is the aphorism that you don’t really understand a topic until you can teach it, or for my illustration, write about it.

    So here are some rituals and communication hygiene I am experimenting with to make sure I don’t lose clarity in pursuit of speed.

    1. Stop, drop, and prompt — I am instructing my agents to push back every time I start a new session. They should drop the shortened session start message and ask for a more in depth version. The pushback will require me to describe the prompt more fully, giving me time to really clarify the issue for myself and the agent.
    2. Pay attention to one session at a time — I often find myself jumping between multiple session threads. It gets easy to do when you the current agent session is working and you can just open a new tab to start a second thread. The goal isn’t to stop concurrent agent work but to stop context switching in the middle of a task.
    3. Maintain an un-siloed context stash — I have a journal for each customer (the main context I am responsible for) with dated MD files. Decisions, communications, and working sessions all get a note. It doesn’t have to be comprehensive, it just has to track the history of the customer in one place. This is all stored in a place where anyone from the company can access it.
    4. Encourage adversarial agents — I work in a small company. Oftentimes, the only eyes on work in progress are my own. Rather than having agents who passively agree, I encourage them to challenge what I prompt.

    I don’t think that P2 is the right tool or culture for every company, but I know the ritual of long form writing is beneficial to me and my work. I am finding my own way to implement clarity in daily life.

    If P2 sounds interesting an you would like to experiment with a P2-like product, another nostalgic A8c alumni has created a version you can manage on your own: https://github.com/georgestephanis/p2026

    Or you can sign up for the hosted version at https://wordpress.com/p2

  • Crash Course in Technical Support

    AI assisted coding like Claude or Lovable make it easy for anyone to create a web app. This type of enablement means that projects can go from ideas to launch really quickly and for, well, anyone.

    But what happens when you get your first users? Figuring out how to support them can take a while.

    I have more than 10 years of experience in supporting customers to help them figure out how to use SaaS products, or engineers in how to extend them.

    Here’s some tips for anyone who is trying to learn support on the fly:

    Tip #1: Take A Breath

    In support, everything feels urgent. Very few people write to support and say, “I’m having trouble, but get back to me whenever you can!”. Rather, messages are, “Hey! It’s broken! My work is blocked! Fix it! Fix it now!”

    It is easy to let their panic generate panic in you. Taking a deep breath, reading through their message multiple times, and having a defined support process will help to support users better. I was once given the advice, “Go slow to go fast”. By slowing down and paying attention, you’ll get a better sense of the issue and make fewer mistakes. Taking the time to really understand the where the user is stuck will fix their problem faster than assuming.

    Tip #2: Respond In A Timely Manner

    No one likes to feel ignored or dismissed. Responding to a user message within 24 hours, or one business day at the most, will let the user know you received their issue.

    Don’t fall into the trap of thinking that an issue has to be resolved before responding to a user. If the issue can be resolved under an hour, then it is worth it to simply fix the thing and send a message afterwards. However, if resolving the issue will take more than an hour, it is better to respond to the user to let them know you received their message, any ideas you have about the cause of the problem, and that you are working on the fix. Once the fix is done, follow up with them to let them know.

    Always execute follow-ups if you promise one. Don’t break the user’s trust by promising an update in 24 hours and then not sending it. Even if the update is “I’m still working on it”.

    Tip #3: Get More Info

    It seems like human nature to share problems rather than describe them. Think of when you taste something and it isn’t quite right. What’s the first thing you do? Shove the spoon in the face of the person next to you, demanding they taste it too. You don’t tell them it is too salty, or too spicy, or too…something. You just share that something is off.

    Often, user’s do the same thing. They write an email and let support know that something is wrong, but they may not think to describe what the problem really is, or how they got there. It may help to create a standard set of questions if it is unclear what the issue is from the first message.

    Some examples:

    • What browser are you using?
    • What type of computer or device are you using?
    • What happened before you got here?
    • Are there any error messages?
    • Can you send a screenshot?
    • Did this work before?

    Tip #4: Clarify Expectations

    What a user expects to happen is valuable information. Once you understand what the user expects, you can clarify if something is actually broken or if the user expects things work to differently than the app was designed.

    Expectations provide actionable feedback to either fix the issue or to consider an enhancement. Remember, fixing everything immediately may not be the right decision. For example, if a fix requires a complete refactor of the code but only has a small number of users who are affected, it may not be worth it. Especially if there is a work around users can be directed to. On the other hand, if a fix is relatively simple, its almost always a good idea to implement it.

    Tip #5: Replicate The Problem

    If the user reports something is broken, confirm that you can replicate the issue. Use a test account (or even better, a testing environment) to follow the actions the user took and see if the same result can be consistently generated. By testing in multiple scenarios, the scope of the bug or issue can be narrowed down.

    Tip #6: Keep Notes On Every Interaction

    When support requests come in, it is easy to get overwhelmed. Notes will help prevent this. Rather than having to go back and re-read every interaction with a user, notes will act as guide posts for what has been done and what needs to be done next.

    Here is a format that I use:

    User: User Name
    Email: user@userdomain.com
    Account/Website/Identifying Information: xxxx-xxxx-xxxx
    Issue: Customer got stuck trying to create a new widget
    Done: Provided instructions on how to create the widget. Provided link to documentation.
    Next: Nothing at the moment. All set.

    User: User Name
    Email: user@userdomain.com
    Account/Website/Identifying Information: xxxx-xxxx-xxxx
    Issue: Customer is seeing an error message when logging in.
    Done: Checked their login information and account. Was able to replicate the issue. Let the customer know I would investigate.
    Next: Investigate the issue and get back to customer in 24-hours with update.

    Tip #7: Track Everything

    If you receive feedback from a user about something being broken, or a feature request, you should keep note of it. This way, if more users contact you about the same (or similar enough) issues, you have data to impact your next steps.

    When something new launches, it is easy to let the urgency and excitement make it feel like every bug needs to be fixed or feature request implemented. However, that’s an easy way to overcomplicate things or dilute the original value of the app. The app isn’t meant to make everyone happy. It is meant to provide a service. Keep your focus on the original purpose and filter out noise as needed. Listening to users is really important. Being mobbed by them is a distraction.

    Tip #8: Improve Documentation

    If users keep submitting the same question over and over again, then it may not be an issue with the app but it might be with the documentation. Public documentation which is up-to-date and easy to understand is a key way to support users who are learning how to use your product.

    Tip #9: Define processes

    As you start figuring out how to help users, start writing standard operating procedures and processes for commonly requested issues. For example, when and how do you give a customer a refund? If there is a bug that needs help from engineering, how do you escalate that? If an account needs to be transferred to a new user, do you allow that? Deciding these types of issues and writing down the process will give a more consistent support experience to your users.

    This can also extend to creating canned responses which can be sent to common questions. This speeds up the process of responding to messages.

    Tip #10: Did I miss anything?

    If you feel there was something I missed, or have a pro-support tip, then please feel free to submit it in the comments!