I'm Michael Pryor, Co-founder of Trello. AMA!

Hi everyone! I’m Michael Pryor, co-founder (along with Joel Spolsky) of Trello! I previously was the President of Fog Creek Software, a bootstrapped software company in NYC started in 2000. We made a bunch of successful things (Trello - acquired by Atlassian in 2017 for $425 MM when TEAM stock was at $24/share - now at $330/share) , partnered with Jeff Atwood to launch Stack Overflow and worked as CFO there for a few years - just recently acquired for 1.8B), a bunch of other unsuccessful things that never saw the light of day, and some things in the middle that were a bit of both.

I’ve been at Atlassian for almost 5 years now as Head of Trello.

Happy to talk about:

  • Acquisitions - what it’s liked to be acquired, what it’s like after acquisition, and years later
  • Work management - my thoughts on the super overused term “future of work” and the tools in this space
  • Finding the right business model, even after having a successful tool - both lessons from Trello and Stack Overflow on iterating
  • Things other people wouldn’t talk about :stuck_out_tongue:

Here’s a SaaStr talk I did right after acquisition, and one a bit after that with the co-ceo of Atlassian - both which set some great context for this AMA.




Note: This AMA is closed for new questions, but you can check out the existing conversations below.

This August 26th, we’re incredibly excited to be hosting Trello’s (and Fog Creek’s) co-founder, Michael Pryor. For almost two decades now, across a dozen or so products, which have included geo-focussed job boards and documentaries that reached DVD players in New Orleans and Kazakhstan, Michael has witnessed quite a bit of the spark and verve of creating things. But also the company-building rigour (scaling multiple product teams to serve millions of users, even being a CFO) that must accompany those creations out into the world.

AMA Index (Michael’s brain-pickings) :brain:

( Hard-won insights, opinions, and observations; thoughtfully examined and articulated )

On the non-linear, strikingly distinctive paths that led to dead-ends and to massive successes
Distill (and document) opinions, trade-offs, founding stories, and principles that have shaped the product; in their case, unpacking: making something “Trello-y.”
Two things that are relevant to any product creator: 1) “over time, your feature requests will just be things other products have.” And 2) “and more to the point, ask your users WHY they are asking for these features?”
How most-requested features and actual product priorities CAN differ. Illustrated with two instructive examples “where our user’s think we are completely wrong (and have thought this for years).”
On pricing: Avoid the long-term, inhibitive price grandfathering tax with transparent time limits, say no to flat rates, and arrive at multiple value axes.
Michael’s notes on the Atlassian acquisition
How following Slack’s promising (from the outside) “fair-billing” approach backfired
Targeting verticals: “be careful that you continue to find new customers that fit that bill (vs. just continuing to rely on the [old] one(s) to guide you)”
The ‘five whys’ for getting to the heart of a customer challenge/request

Further reading/listening/pondering from the interwebz :open_book:/:headphones:

(Other insightful excerpts drawn from blog posts, interviews, and conversations)

On the transition to building a massively horizontal product:

You’re right that most of the people that knew about us, knew us from Fog Creek…they were mostly developers. We also co-created this company called Stack Overflow, which, if you’re a developer you know what Stack Overflow is. It’s a Q&A site for devs. And so, that was most of the people that saw the app in the very beginning.

And, that was a weird dilemma for us, because what would happen was, people would show up and they would start asking for feature requests for things that they had seen before. Things that were very appropriate to their work and who they were in their role.

We sort of had to ignore it a little bit. Everyone says, ‘listen to your customers.’ It’s a little trite. Who else are we going to listen to? And I’m not going to say, ‘don’t listen to your customers.’ But I think like, the lesson there was, when people would come to us with a feature request. They were telling us something they had seen before.

And our trick was to build something that people loved because it wasn’t like anything that they had used before. So, if all we did was listen to the feature requests that they asked for, we would just end up with the same tools that were already out there.

So, what I told people to do and what we sort of learned to do, was to listen to the pain that people were having. So the first thing that they’d do is say, ‘here’s how to solve my pain, all you have to do is add this feature…’

I think the trick is, you had to ask them what the pain was that they were having. And think about that pain from the perspective of other people that are not developers. The trick with building a horizontal app is you can’t put a very specific feature in there that solves one person’s problem, you have to build a feature that solves most everyone’s problem.

Source: Traction Conf | 2017

On the fundamental distinctions between Salesforce and Excel, and deeply knowing the kind of software you’re building:

The problem is, every time you’re adding features, you’re creating a more complex system. And that’s what developers do all day long. You think of an abstraction and you create code around it. And then you present it to a person. Devs are really good at doing that.

But when you have that system and people come into it, then you have to explain to them what it does. So, for example, you use Salesforce, you’ve got to come up to speed on what a lead is, what a contact is…there’s all these concepts in there, all these rules around it.

Once you understand that, Salesforce becomes a very powerful tool to use as a sales person. And because Salesforce, the app, knows about the data that you’ve put into it. It can tell you all these amazing things. I can be like, ‘hey, your pipeline is too short, you’re going to miss your quota next month.’

In Trello, we’re trying to do something more akin to what Excel did. Which was, we’re going to give you some building blocks that’s going to solve the problem the way that you see the problem. I’m not coming into a very specific role and saying, ‘hey, you’re a salesperson, these are the tools that you need, these are the objects in your world.’

You can add labels to cards and that can be whatever you want. I don’t have a preconceived notion of how you work. So Trello is allowing you to build that system as you go. In the same way that when you put data into a spreadsheet, you start to tell excel, ‘well this column represents this.’

Even when you go to add a chart in excel, you kind of have to tell it, what you want it to chart. It doesn’t know. Whereas, like in Salesforce, you can be like, ‘here’s your bookings next month.’

So building a horizontal tool where you don’t know exactly what people are going to do with it, you have to think about giving them really easy building blocks. It’s tricky, because then, there’s a little bit of work that they have to do. But it also means that it can be applied to so many different situations.

Source: Traction Conf | 2017

On not reinventing the wheel with pricing:

This is a common thing that people do when you first start out, you’re like ‘I’ll charge people a flat fee, like $50 bucks to use my product.’

But then it doesn’t matter if you’re a tiny company using your product or a big company.
People don’t want to charge per user because in a collaboration product that is a vector of growth.

But for all intents and purposes, that’s also a measure of value. A bigger company gets more people using it and more value, and at this point in time everyone gets that.

So making up your own weird pricing scheme is always dangerous, and when you get to a point where people are just like, “Yeah, I get it. You pay for storage, you pay per user.” Doing what other people— What the market has now accepted as normal is often very advantageous. You do not need to reinvent the wheel in that area.

Source: Heavybit | 2019

On the enduring influence of his co-founder, Joel Spolsky:

I connected with my co-founder, Joel Spolsky, back in the days when I was working at an Internet startup in New York City. At that same time, he was the program manager of the Excel team at Microsoft. When I was working at this company, I was trying to build something in Visual Basic and most of the developers there were Linux devs, so they always referred me to Joel because he’s a Microsoft expert. So I just kept going to him with questions and he was very generous with his time as he was always working on some other things.

Over time, we developed a relationship as friends. And when the time came to start a company, I told him that we should do it together. Prior to that time, he had quit his job and was taking time off. I also quit my job so that we could start working on the company. Even though he had vast experience more than me, we split the company’s equity 50/50.

I think learning from him and being present for that early stage growth of our company and riffing on the ideas about our structure of compensation for people and the kinds of benefits that we wanted to provide and building a software company in New York was of unheard of. Joel had a huge impact on me and has been a big mentor to me in my career.

Source: Authority Magazine | 2020


Hey Michael,

Big fan, here!

I’ve long followed the Fog Creek journey (through Joel’s amazing blog) and I’m certain that a lot that we learned from it, contributed immensely to us founding Chargebee. So, really glad to have you on Relay. And thanks so much for taking the time!

As they say, innovations are only judged/measured in hindsight, and you’ve been at the helm of so many industry-defining products. You’ve also mentioned in interviews, how Fog Creek began with an almost product-agnostic approach. The idea was to get great people together and see what happens, right?

I’ve always wondered what were some of the operating principles that emerged as you did that, leading to such a consistent list of impactful products in that first decade. How do you go about reviewing and learning from decisions, for instance? I’m sure there’s a ton that even single-product companies can take away from that. Thanks, again!


Thanks for doing this, Michael!

I guess almost all of us here would have used something you’ve developed over the past two decades, so it’s quite exciting to host you.

You’ve said somewhere how the humanity of software is what differentiates products in today’s low-barrier-to-entry SaaS world, where each product has dozens, if not hundreds, of alternatives. So when it comes to product strategy, how, in your opinion, should a product north star be approached by a founding team that is just getting started.

Oh, and on that note, I’d also love for you to tell us all a bit about ‘Aardvark’d,’ the documentary you made and retailed on how modern software gets built. :slight_smile:


Hey Michael,

Thanks for doing this! :pray: 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.


This is great. :slight_smile:

Thanks for taking the time, Michael!

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?


Thanks for doing this Michael!

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.


A massive congrats to you and your team, Michael for the amazing journey!

What’s it like when Trello got integrated within Atlassian? We’re users of both products, so it made sense when the news came. What changed within your philosophy of building products?

Can I also ask about the acquisition process - what were your learnings and what would you not do again, if you had to do it again?

Thank you so much!


Hi Michael,

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?

Best regards


I’ve got another one, Michael. :slightly_smiling_face:

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.


You can actually watch that documentary here: Aardvark'd: 12 Weeks with Geeks - YouTube (I don’t know if it aged that well lol or if I’d call that “modern” anymore).

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:

  1. 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
  2. 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 :slight_smile:


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. :rocket: :zap::zap: 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! :raised_hands:

1 Like