To see our general page on building the Landing page, go to Chapter 3: Landing Page

Here, we prepare the language, copy, selling points and image (or other) assets for the Landing page. We'll list out all of the features of the product, and really try to sell this product to potential users.

We'll have to be very clear about the pain point that we're trying to solve. So we'll need to provide good examples of issues that potential users might already be facing, and how this product solves that for them.

We followed the guide from klientboost.com to help us work through how to develop the copy for a landing page, just following their step-by-step tutorial. It was very helpful.

Steps

Step 1: Identifying the audience

  1. Developers who have to present their progress to non-technical audience
  2. Project managers
  3. Any one who directly works with or tangentially works with Github

Step 2: Choose the desired action

  1. We want people to sign up for the waitlist
    1. Help us identify if there is any demand for this solution
    2. Start slowly rolling out this product to users in a drip fashion
  2. even after product is ready and launched, we still open up the product to people on waitlist first.

Step 3: Identify the Core Problem

  1. Not being to organize and show my Github issues in flexible groups
  2. Kanbans are too rigid
  3. Issues can only be in 1 group at a time, but they conceptually should be able to exist in multiple groups at the same time
  4. Could not present issues in a way that promoted a healthy discussion with business side
  5. We want a more fluid way of organizing Github issues
  6. Can’t communicate what you’re working on? What issues are important? Which issues we should focus on next? What issues you finished in the last 2 weeks?
  7. Are Kanban boards too rigid for discussion purposes?

Step 4: Write the value proposition (hero page)

  1. Create a powerpoint presentation with your Github issues
  2. Showcase your Github issues to promote a healthy discussion with stakeholders
  3. Create “views” using Github issues
  4. Organize your Github issues in a way that makes sense to normal people + non-developers

Step 5: Write the follow up

Problem paragraph

  1. Are you tired of copying and pasting Github issues into another format when presenting your progress with product manager and stakeholders?
  2. Do you feel that Kanban boards are too rigid?
  3. Do you need to place Github issues in more than just 1 “column” at the same time?

Some more

  1. Are you having trouble getting your managers to review the Github issue list?
  2. Do you use Github issues to track your project's progress, but can't get your managers to review your progress?
  3. Is your management team unfamiliar with how to use Github? And they don't look at the issues?
  4. Do you want to use Github issues to show your team the progress of your project, but without having to teach them how to use Github?

Solution paragraph

  1. GetGitMe allows you to connect with Github and display issues in the way that you want. You can better present your project to your team, your managers and your stakeholders.

Step 6: Write the how

  1. Create custom views and drag Github issues into them to promote proper discussion with management
  2. Place the same Github issue in multiple views at the same time
  3. Organize your issues in a way that makes more sense to non-technical stakeholders, not just developers

Step 7: Include the Social Proof

Step 8: Add the final CTA

  1. Sign up to try this out
  2. We’ll bring you in on a rolling basis so we can get your feedback and help you use the product successfully.
  3. This will be an email form field.