I recently built a GitHub Markeplace [0] app Pull Reminders [1] and have been really impressed by GitHub's ecosystem strategy. They seem to taking lessons from Slack's success and doubling down on supporting integrators who provide valuable apps and features built on top of GitHub (ie. TravisCI, ZenHub). I hope this direction continues under new ownership.
GitLab on the other hand is focused on solving every facet of the development lifecycle within their core product. From their blog post about GitHub's acquisition:
> ... instead of integrating multiple tools together, we believe a single application, built from the ground up to support the entire DevOps lifecycle is a better experience leading to a faster cycle time.
It will be interesting to see how the different strategies play out.
GitLab has always demanded too much faith from its users.
First with CI, it was the all-or-nothing approach where you couldn't use GitLab CI with any other provider. Lately they have tried to fix this but it was a half-hearted development after a lot of complaints.
Lately with their DevOps approach, it's exactly how you've said.
I don't have trust in GitLab leadership and their product feels way too bloated.
You've got your 30-second teaser video, clear call to action, social proof, many channels of communication, key features identified under-the-fold for more interested individuals, trustmarks (your Guarantee), etc.
I don't see any major offenses. It's standard. The only thing I'd recommend... include a call-to-action visible no matter where the user is on the tour page. (One the scrolls with the user, perhaps?) You don't want the user to search for it after they're satisfied that your product is what they need.
If you'd like more specific feedback, please be more specific with your request. By not investing the time to direct me to specific items which you are currently trying to improve it shows me that you are unappreciative of my time which I am freely offering, don't have a specific thing you're attempting to improve, or both.
Thanks Mike. I'm sorry I wasn't more specific. The feedback you've provided is actually very useful since we redesigned the page just last week with the things you mentioned in mind.
Overall, we're working on properly communicating to our particular audience/demographic... old school guys. We don't want to make our product look cheap but we also don't want it to look too expensive.
These items all help to complete an "ideal" landing page, but the honest truth is there is no recipe or checklist. While a site developer USED to get points for including all of the aforementioned accouterments on a landing page, today it is standard fare.
As far as reaching out to your target market, see if you can arrange some sessions with people in your market. Show them the site and ask them to talk about their perception, thoughts and questions while they look around. There are sites that offer a service like this but don't necessarily target your market appropriately. I haven't used many of them, but I've heard great things about askyourtargetmarket.com.
Generally speaking (Basecamp user here), I feel like there's too much noise and it's difficult for me to focus and navigate through what I need to get done daily.
I've struggled to find an efficient way to do this for years so I built an app for this... I still don't know how useful it is for people out there, and I haven't decided if it's worth turning into a product.
We actually started out by displaying user flows as flow charts... we quickly realized that flow charts are an inefficient way to display a comprehensive batch of sequential user actions and application flows. It IS easier to type outlines in a text editor than mess around with flow charts.
We transferred that realization to this web app.
Our user actions are linked to application screens, which gives you a good overview of how your user interacts with your application.
We tried both ways, and the free trial was a clear winner. I think this could depend on your service, however.
Something else to consider: even though we had more people sign up and pay, we also had far more people sign up and try without paying. Several of those users also gave us free, insightful feedback. Especially if you are starting a new service, this is worth more than the paying customers who give no feedback.
Cost of provisioning and supporting was already mentioned - that's big .
Another key point to consider is the amount of effort required from the user in order to derive value from your product. If the product can be used easily and passively (e.g. Pandora) than a free signup makes the most sense.
If your product requires higher user engagement to be useful - i.e. they need to dedicate an hour or two to working with it, or need to integrate with something, than a refund or out may make more sense - many people treat free trials as worth what they paid for them - nothing. If someone has to pull out a CC, they have more likely overcome the hurdles necessary to engage with your service.
Even if someone has split-tested, the specifics of how much the product costs, what it provides, how much time it saves the user, and its perceived value all make a huge difference on where the split-testing ends up. Apples and oranges.
GitLab on the other hand is focused on solving every facet of the development lifecycle within their core product. From their blog post about GitHub's acquisition:
> ... instead of integrating multiple tools together, we believe a single application, built from the ground up to support the entire DevOps lifecycle is a better experience leading to a faster cycle time.
It will be interesting to see how the different strategies play out.
[0] https://github.com/marketplace [1] https://github.com/marketplace/pull-reminders/