Aha! Blog
blog.aha.io · Company blog · on HN since 2013
The Aha! team, makers of product roadmap software, write about product management, engineering teams, remote work and hiring.
What HN saysMostly shared by Aha! employees themselves, who link posts on remote work, cover letters and the minimum lovable product to back up points in discussions.
19HN people shared it
6linked it in comments
345stories submitted
1.4Kstory points
7 years agolast shared
2013people per year2026
Most-shared posts
- 1Product Managers, Stop Pissing Off The Engineers3 people · 40 points · first shared 2013 · 60 comments on HN
- 2The 2017 New Normal for Engineering Teams2 people · 10 points · first shared 2017 · discussion on HN
- 3This Is How to Build a Collaborative Text Editor Using Rails2 people · 9 points · first shared 2018 · discussion on HN
- 4How I Convinced Our CTO to Switch from CoffeeScript to ES62 people · 7 points · first shared 2017 · discussion on HN
- 5The new journalist is an algorithm2 people · 3 points · first shared 2014 · discussion on HN
- 6Remote Workers vs. Office Workers2 people · 3 points · first shared 2017 · discussion on HN
- 7The Minimum Lovable Product (forget the MVP)2 people · 3 points · first shared 2013 · 1 comments on HN
- 8Pissing Away Our Money With Google Display Ads2 people · 2 points · first shared 2014 · 1 comments on HN
- 9Hey Engineers — Stop Pissing Off Your Product Manager2 people · 2 points · first shared 2013 · discussion on HN
- 10How to run a great Beta program - a contrarian view2 people · 1 points · first shared 2013 · discussion on HN
- 11Pissing Away Our Money With Google Display Ads1 people · 172 points · first shared 2014 · 72 comments on HN
- 12How I was unbanned from Hacker News1 people · 72 points · first shared 2013 · 50 comments on HN
- 13Kanban can not save you from the engineering death spiral1 people · 62 points · first shared 2013 · 64 comments on HN
- 14Kanban – The Secret Engineer Killer1 people · 43 points · first shared 2013 · 63 comments on HN
- 15Hey Sales Guy - Stop Pissing Off The Engineers1 people · 30 points · first shared 2013 · 24 comments on HN
What HN people wrote when they linked it
peterlk · 2018-10-08
I wrote a full comment and then deleted it because our blog talks a lot about this. At the risk of being downvoted for pushing my employer's blog, I'll leave you with a blog post:
https://blog.aha.io/remote-workers-vs-office-workers/
Notable bits:
> People get more done when they have autonomy
> the office is filled with distractions. This is especially true for those who are in an open-office space, where they are 15 percent less productive, have more trouble concentrating, and are not too pleased with their sound privacy.
> People are often surprised to learn that remote workers are actually more engaged than in-office counterparts. [0]
> Perhaps the greatest benefit of remote work is that it makes the way for sustainable happiness — giving people the chance to pursue their passions both in work and in life
And this is not said in the article, but happy people produce better work.
Also, there are more sources in the blog post.
We've written a lot about it, if you want to read more: https://blog.aha.io/?s=remote
[0] https://hbr.org/2012/08/are-you-taking-your-people-for
mtrimpe · 2013-08-19
The article is also the first of it's kind I've seen that gives salespeople comprehensible and actionable advice on how to improve.
If they're salespeople worth their salt they'll be able to help leverage this newfound understanding to better sell their feature requests.
I do agree that ideally this nuggets of wisdom would not have been hidden in such a ranty article though.
P.S. Their equivalent post aimed at product managers is at http://blog.aha.io/index.php/hey-product-managers-stop-pissing-off-the…
schneidmaster · 2017-12-15
My company wrote a blog post a while back with some tips for a good cover letter -- it's not specific to engineering but I think it's super helpful anyway: https://blog.aha.io/the-best-cover-letters-that-ceos-love-to-read/
Two key takeaways (in my opinion):
- If you care about the job, do a little bit of research about the company. What does the job posting focus on and how do you align with that? What's their engineering stack and when have you worked with those technologies? This isn't "required" (i.e. you can certainly find jobs by mass-sending the same generic intro) but investing a little time in finding out about the company goes a long way towards telling them that they should take the time to find out about you in return. I also think this helps with the question of tone -- you probably won't go wrong matching the tone of the job posting itself.
- Make it easy for them to see if they want to hire you. Include your resume and make it easy to read (a short, well-formatted PDF is great). Include a direct link to your GitHub/portfolio/etc. If you don't have any public work, just say so and give them a Cliff's notes instead -- "Most of my recent GitHub contributions are private, but for the past six months I've lead a team of four developers in developing a new widget using React, Redux, and ES6, which I see is a close match to your tech stack."
k1w1 · 2013-08-12
I am the lead developer on Aha!. We built it to help product managers and developers collaborate on features and roadmaps. We have been working around the clock (well, almost) for the last few months and today we finally allowed open signups. We ran a private beta (http://blog.aha.io/index.php/great-beta-programs-a-contrarian-view) and got lots of great feedback from a group of really engaged users. This was a big change from my previous startup where we ran an open beta and had thousands of users, but little useful feedback.
I have been writing Ruby on Rails applications for a long time now, but it was a real pleasure to start from scratch using the latest version, and all the wonderful gems that are now available.
We wanted the UI to feel really responsive, and to allow almost real-time collaboration by multiple people. The underlying technology is Rails, with as little Javascript/CoffeeScript as possible, but with extensive use of Faye (http://faye.jcoglan.com/) to enable real-time notifications between users, and also to update the screen of the current user in response to their own changes. This allowed us to focus more energy on the Rails backend, and put all the business logic in one place without giving up the real-time user experience that a Javascript framework provides.
Between Faye and Rails' Turbolinks, I've been really pleased with how easy it is now to get great performance out of a Rails app.
bdehaaff · 2013-07-23
I think you can read the post and come to a very different conclusion and one that I have written about in the past.
The MVP is a curse for ambitious technology companies that want to grow. In an increasingly transactional world, growth comes from long-term customer happiness. And long-term customer happiness comes when customers adore your product or service and want you to succeed. You should be thinking about what it will take for customers to love you, not tolerate you.
In this case, insights from the data about the agriculture is what customers really need. And if you give it to them in a meaningful and actionable way, they will love it (at least that's the theory). That's radically different than what might be minimally viable (e.g. a ton of data that they could sift through in Excel).
Really think about the type of mindset change it would take. What would it take you to create a Minimum Lovable Product (MLP)?
http://blog.aha.io/index.php/the-minimum-lovable-product/
this2shallPass · 2020-05-03
Varies, but generally a product owner is focused on taking the strategy and translating it down into actionable tasks. They work across teams and roles to make sure the team is executing properly. It tends to be more tactical than strategic. They don't have to know how to sell or market products well, or how to get those products into the market successfully. On paper (a narrower scrum view) they are responsible from sprint planning, to daily stand ups, to review, to retrospective. Not the larger backlog prior to sprint planning, and not what happens after some software is accepted as done / to be shipped.
Some links:
https://www.productplan.com/product-manager-vs-product-owner/
https://blog.aha.io/the-product-manager-vs-product-owner/
https://blog.aha.io/product-manager-vs-product-owner-vs-project-manage…
https://www.productplan.com/glossary/product-owner/
https://blog.aha.io/the-product-vs-project-vs-program-manager-role-con…
https://www.mironov.com/?s=product+owner