Use the inverted pyramid method. Give the most important non-contextual piece of information first, then add context afterwards. For example, for Panem, a tool made to help on-call engineers manage their Runbooks better, we answered the question "*Why did you pick this idea to work on? Do you have domain expertise in this area? How do you know people need what you're making?*" (which btw is really like 3 questions in one) first by: > We’re both engineers who have experienced firsthand how much time is wasted by on-call tickets that may already have well-documented solutions. > >We came up with the idea because at every company we've worked at, it's been an ongoing issue and a constant overhead time waste for our entire team. > >I (Stephanie) worked at Amazon and was surprised at how inefficiently their runbooks were managed. However, I was even more surprised when I moved to my next company, Fabric, to find out they had no runbooks at all. I was the one who created and maintained the system for my team, which was a nightmare without a dedicated tool. Even with a runbook system in place, we’d still spend 20-30 minutes per ticket just searching for a relevant solution. > >Having dealt with these issues so often, and personally onboarding my organization onto a system, I have gained very clear, unique insights into how a platform built around this problem should function. > >We know people have this problem since it’s been a noticeable time waste and issue for the five companies we’ve cumulatively worked at, as well as our engineering friends and coworkers at various other companies like Amazon, Fabric, Shopify, Stripe, and more. As an example, Shopify created a small Slack chatbot that searches through their docs and tries to suggest a solution from their runbooks. Some companies have pseudo solutions, but nothing long-term or scalable. However, the most important parts of that snippet that actually answer the questions, are hidden within the paragraphs. So we can extract them out and have a more clear inverted pyramid style answer like: >We’re both engineers who have experienced issues with on-call runbooks firsthand for years. Also, I (Stephanie) personally onboarded my organisation onto a self-made runbook system and have very clear, unique insights into how a platform built around this problem should function. > >When I worked at Amazon, I was surprised at how inefficiently their runbooks were managed. I was even more surprised when I had to put together a handmade system from scratch for my next company, Fabric, because they had none. Even with a basic system in place, there were still numerous time sinks for the entire team that could have been solved with a dedicated platform. > >We know people have this problem since it’s been a consistent time waste and issue for all the teams at the companies we’ve cumulatively worked at, as well as for our engineering friends at other companies like Amazon, Fabric, Shopify, and Stripe. As an example, Shopify created a small Slack chatbot that searches through their docs and tries to suggest a solution from their runbooks, albeit not very accurately. Some companies have created internal pseudo-solutions, but nothing long-term or scalable. By having this line first, it answers all 3 questions. Then we can give context afterwards.