Thanks for doing this! Really looking forward to the AMA.
You’ve said that in the early days of Trello you had to deliberately learn to draw wider patterns from a narrow source of feedback, as mostly developers were the early users. Now that you’ve been building for an ever-widening broad base of users for close to a decade, how differently do you think about making sense of feedback today? Any trusted product frameworks you could share would be super helpful.
Thank you so much Michael for offering to do this AMA.
I’ve used Trello for many many years and have always been inspired by the team and business. I never knew much about the approach though so reading your intro here has been fascinating for me.
Can you share any of the most heated debates you had internally with specific features to build / not build at Trello?
Your approach to actively refusing to build features for specific use cases is refreshing, and I can imagine would be very challenging internally when you have opportunities to win big customers “if you just built this one thing”!
Similarly, I can imagine existing customers may have chosen to stop using Trello at some point to use a more focused tool. How have you managed to keep that focus and approach at the toughest moments?
Thank you for putting something amazing into the world and building a product and business that has inspired me for years.
Keen to hear, when it comes to iterating on the right business model, what are some of the must-have inputs you factor in as a founder before betting on a given iteration? And how differently do you approach these based on the stage that a business is at?
Would love to learn from your thoughts on how should one think about PLG and a top down sales motion running in parallel and how should an early stage org approach it so that they complement each other instead of going after entirely different user segments.
Congratulations on building a brilliant product and your amazing success! Thanks so much for doing this AMA with us. I loved the point you made about selective listening when it comes to customers. Listen for pain points and not for feature requests. Could you share some ideas on how to find out what the true pain points are from customers? How did you nurture your customer advocates and how have they helped you grow your product?
Really liked your point about how when it comes to pricing especially, following what the market agrees upon is mostly advantageous. I’d love to hear the flip side of it. Over all these years of building and scaling, what have been some areas (and instances) where following the market’s cues/standard practice has actually been disadvantageous?
Great question! What seems consistent to you though was far from consistent. Some times we built the right product at the wrong time (ten years ago we worked on remote work audio software that made virtual rooms for people and I think there are 4 startups I know of working on this today), other times it was the wrong product at the right time, or we got everything right but failed to market it correctly (we built screensharing tools before logmein/gotomypc but pitched them as tools for customer support agents limiting our total addressable market). Additionally, you wrote “first decade” but most of the “hits” you know about today were created after 2010 (whereas we founded Fog Creek in 2000).
Stackoverflow was a great idea that Joel had and an amazing product that Jeff Atwood built - but the reason it worked so well in ADDITION to the product was that both of them had spent a decade building up a reputation with developers through blogging. If that hadn’t existed, I don’t know if that product would have succeeded so well.
We also struggled sometimes trying to figure out how much longer to work on something before calling it quits (I get domain name renewals still for projects that we eventually stopped working on).
I know none of that is really an aswer - but it’s just to say, none of it is easy. Often one thing we did is we showed people the behind the scenes of what we were doing and why (think the early days podcasts talking about Stackoverflow or Joel’s blog articles on Fog Creek and our bug tracking product FogBugz). For the audience we were reaching out to (mostly developers) this worked really well.
Trello on the other hand didn’t get much of its inertia from that - instead it was more our brand, and the flexible features of the product that drove its growth. We wanted to add features that let people express themselves through productivity software (which wasn’t normal at the time). Board backgrounds, cards that titled when you picked them up - we let people put more of their personality into their organization and it resonated. See more on this topic here.
If you are just getting started - I suspect most teams will be building something to scratch an itch in some way. They will have some opinion about how their product should work (and likely work differently than what is out there already). If you spend time thinking about that story, and work hard to put it into words, you can get something like this: Trello’s Product Lead on the Unique Ramp to a 10-Person Product Org | First Round Review
In our case, we spent a bunch of time calling those things making something “Trello-y” before we realized that was super vague and totally not helpful to new people joining the team that didn’t understand all those tradeoffs or decisions that we made.
Great question! Initially, yes, developers weren’t our target market but they made up a disproportionate number of our users - so this was tough to kind of take their requests with a grain of salt. But I think two things are more relevant to any product creator:
over time, your feature requests will just be things other products have. You might need these features, but be careful - if you just spend all your time copying other tool’s features, you will have no time left to innovate. Your product will just be a bad clone of those tools
and more to the point, ask your users WHY they are asking for these features? “What are you trying to solve? Tell me about your workflow”. If you are building a more horizontal tool that might be used by lots of different types of people, you have to synthesize a lot of feedback that is specific to a particular person’s workflow and create features that work for people across the board
I can point to a feature that has been asked for many many times and we haven’t built - not because we didn’t want to, but simply because it just never rises up the priority queue: https://community.atlassian.com/t5/Trello-questions/Can-I-add-more-color-label-options-to-organize-my-cards/qaq-p/585754
If you read that thread, you can see that our interpretation of priority doesn’t match a lot of user’s interpretation though. This wasn’t really a heated debate (we’ve tried to solve it during our internal hackathons as well, but it just hasn’t made it to production), but I thought it was instructive to show a case where our user’s think we are completely wrong (and have thought this for years). FWIW, based on this thread, it seems like this could be a good paid feature tbh.
The longest running internal debate though for Trello is a concept called “mirrored cards”. Also called “quantum cards” internally - the idea is for a card to exist on multiple boards at the same time. Or it might be described as cards that sync across boards. The implementation might be different but the experience for the customer would be something like “I have this card on my team’s board and I want to see it on my personal board as a reminder to me, but it really lives on my team’s board”. There are lots of tricky questions to make this work, and actually we thought we had worked through almost all of them (and avoided syncing data around all over the place), and after what I think has been probably 6 or 7 years of talking about this, we built it. But the way we architected it didn’t fit with our overall strategy of how we wanted cards to evolve and so we didn’t ship it.
Mirrored cards gets into really interesting questions about what Trello’s product tenets are - do cards always have to live on boards? Can they live on more than 1 board (or do they just appear in other places like shortcuts in file systems do?) Do all boards belong in workspaces? When I change the filter on a board, do you see the filtered view if you are a different user looking at the same board?
I think it’s really useful to ask those questions and understand that you CAN change the answers to them. You just have to recognize when you are making one of those changes because it can be a big bet.
I love this question. I think it’s natural to always be modifying your business model.
Recognize that if you choose to change things and leave your current customers in place (With their old price, or their old features) that you are kicking a can down the road. The best advice here is to give them a timeframe when you do this. For example, let’s say you raise your prices, but only on new customers. Even if it’s 5 years, you should tell your existing customers to expect an increase after x time. If you don’t, eventually, you will realize that having people on different plans starts to create product debt for you (and possibly technical debt). The support team always has to remember that their are old plans. Your financial reports have to remember this as well. It’s a long term tax on your business to have to carry these old plans forward, so setting a time limit is transparent and fair (even if customers want their price to stay the same forever).
Also, try not to make this mistake - charge a company a fixed price for unlimited use. The revenue you make should scale with the value given to the company (even if your $/user goes down as you make more money). Per user pricing does that. There are other methods as well. But one fixed fee is usually a mistake companies make early on that they have to undo later.
Also try to eventually get to a point where you have more than one pricing axis. If you have a SaaS business and you charge per user, then a company that has 10 people can only pay you so much until they add another employee. But if you have multiple plans (gold, silver, platinum - or standard, premium, enterprise) then you can upgrade that team to a higher plan (so two axis). Having more than two is even better but can make your billing start to get a wee bit complicated.
Thanks for asking! We made sure the two fundamental things were aligned - our values, and our belief in the product. And because those two things were shared, even though there was (and still is) a ton of work to do, I knew we could do it.
On the people side, navigating the change from the team identifying as Trellists to Atlassians was a process that just took time. It couldn’t be rushed. And even now 5 years later, defining the identity of our Team (the Trello team) within Atlassian, just like any other product team inside Atlassian, is an ongoing process. In some ways I think we’ve looped all the way around and all the new people on the team are eager to learn about what makes our team unique inside Atlassian.
One thing we practiced during the initial days of acquisition was a “do not disturb” policy for the rest of Atlassian - so our small team could continue to deliver product value without getting overwhelmed. This was an amazing idea and worked super well. In hindsight I think we should have been clearer about when this policy ended because there were a lot of strategy things (like moving all Trello accounts to be Atlassian Accounts) that took a really long time to execute and I wish we had started sooner.
We also had a lot of other Atlassians join our team at points when we were hiring, and this was SUCH A BIG HELP. Having actual team members who were versed in the overall strategy of Atlassian, but working on Trello side by side with the newly acquired allowed us to share perspectives with each other and learn from each other directly.
Looking at the Atlassian stock price since acquisition, in hindsight I would have done the deal as ALL STOCK
Slack had a pricing policy called “fair billing” where you add all your users but Slack only charges you for people that login. If you pay yearly and someone doesn’t log in after some sort of time, they credit your account. I loved the idea behind this and we copied it at one point.
It really failed us. I appreciate the spirit of the policy but the actual mechanics were confusing to people (“Why am I getting a credit for $0.33 on my bill?”) and made people angry (“I budgeted x for this tool, and your invoice isn’t x. This is making things difficult for me!”) and the accounting statements were impossible to read ("$2.40 credit for Jim because they are inactive. $3.76 charged for Sue because they became active").
So it was very short lived and we switched away from it. We didn’t really consider the type of tool that Slack was, and what customer’s expectations were.
Another story: I remember Dropbox had a plan for like $15 for five users. You couldn’t buy less than 5 users though. If you had 4 ppl, you paid $15. If you had 2, you paid $15. The nice thing was this cut out a lot of noise that can happen when you look at logo churn for example, or count your customers, or other things where tiny teams or single user people can make the numbers look strange. It also can make things less expensive for small teams because then they don’t feel the additional cost of each user at first. But then at some point we talked to someone from Dropbox and they told us this was a huge mistake and they really wanted to make it per user or maybe 2 people for $10 because all the teams that were 1, 2, 3, or 4 people were annoyed that they had to “pay for 5 people when they were only 3”. Perception played a huge role in this not working for them. They thought the pricing was doing their users a favor, but it turned out it was working against them.
Hi Michael, another huge fan here. I was a Trello early user and used it for years as I started a few startups…what an amazing product and company you’ve built, I really do wish -and work- to achieve something like what you have.
We’re building a project management platform but for construction…scheduling, planning tasks, resources, things like that.
We’re struggling constantly with prioritizing features that users will love and will make their lives easier. We are talking to our users every day, getting feedback, mockuping and iterating, yet we still struggle to build robust but easy to use features. Construction needs robustness to support complex Gantt charts, and resource management and other things, but we also want to build easy to use, beautiful product…features they love and enjoy to use…
What would you recommend to a startup like ours? focus on better UX/UI to make it easier, launch more features than the competitor, make it simple, focus on one thing and do it great, integrate with other software, focus on mobile…there’re so many things to do that it becomes really hard to prioritize, especially with a small team. I know it’s hard to give feedback from outside but any ideas would be appreciated.
We know this industry really well and we understand our users but it’s hard getting traction like a product for startups would…
Looking forward to hearing from you, any piece of advice you can give! Thanks in advance
An update: What a great delight it has been to come across @michaelpryor’s ear for cadences, hums, and patterns that inform enduring products. Copious note-taking must ensue. :)) Michael had to leave a little early and shall be tending to the rest of the questions later. Thanks, everyone, for attending with these thoughtful inquiries!
Early on, my recommendation would be to find the people that you think are a great target market for you and honestly - just build what they want. I think for vertical solutions like this, that’s the simplest cycle. Just be careful that you continue to find new customers that fit that bill (vs. just continuing to rely on the one to guide you).
Similar to Five Whys you can just keep asking the same question to customers to get to the root of what is going on…
Customer: “We need this export feature so I can send this report in Excel?”
Customer: “My boss wants this report emailed to him on Friday and he only uses Excel”
Me: “Why does he need the report?”
Customer: “He wants to see how many tickets we’ve answered.”
Me: “What does that tell him, or in what cases would he be surprised or worried? Too few tickets? Too many?”
Thanks so much, Michael! Your humility shines through these responses. Thanks also for sharing a pricing decision that arose from following a leading company like Slack and that eventually backfired. Such a great lesson there on understanding one’s own context.
“None of it is easy,” you’ve written. And I agree. What really helps is founders like you and Joel, taking the time to share their unique journeys with admirable openness.