Been following this series produced by the folks at Linear. Sharing here with each and my own takeaways
Dick Costello Notes:
Builders who understand design do better and succeed at building what the customer needs/wants/buys. You can feel when this is true in a product.
Flexible tooling makes adoption accessible
Things go from quality to trash one step at a time, not all at once
Dogma creates patterns that can be harmful
What we shouldn't do is as important as what we should
Stay small
Katti Saarinen Notes:
Company values are often disconnected and in the end useless
There's a desire to change everything when growing, keep the parts that work or are good
Trust among founders, team, key to foundational team and growing.
Another vote for stay small.
Follow intuition and validate it to train it and keep it in check
Target your audience deliberately with every choice "issue tracking vs task mgmt" obvious but not really when folks don't know or understand their user or are searching for a fit vs built for a purpose.
Quality - It's not worth doing things badly, companies give up on it because it's not easily measurable.
If leadership doesn't believe in building quality software, the company won't ship it
The path to winning in a competitive space is to be the best at everything
Values should be timeless and connect to success and mission of the company.
Jeff Weinstein Notes:
Obsessed with large problems, maybe success as well?
Sees past business failures as errors in strategy, not picking a big enough problem to be economically viable
Sounds like 'economically viable' means, public? not the measuring stick I would use for success.
Plenty of great sustainable 2-3 person teams and products out there.
Linear for example is ~ 50 people and profitable so 🤷
Listen instead of pitch
If you focus on the right problem it's easier to build something purposeful and of quality
People do associate well designed software with things that will work
Problem identification starts with listening empathetically
Henry Modisett Notes:
Building a new design team, looks for complementary skill sets that are missing with each hire.
Hire the folks who're going to die if they don't make the best thing because what you're building is meaningful to them vs the folks who're just happy to do what they're told.
Strike a balance between process and pushing / building ideas forward
Speed motivated, for some personal reasons
In the very early stages, made great mock ups and then just done as a designer... the whole point is to make the thing for other people and when we're not getting there or getting there frequently it's frustrating and feels slow (as a designer)
Working fast isn't the 'right' way that everyone should work,
What they've chosen to do is work quickly but revisit and follow up on the areas that they shorted in favor of speed (lots of folks say this will happen, rarely does)
Decisions need to be made, not the same person always but on each project, decision making in areas is key to moving fast and forward.
For many great reasons companies go slow
They've broken up designers by platform to reduce the speed of decision making
Software can be changed, users won't remember the thing that was worse, who cares just make it better.
You have 200 users today but 300 new ones tomorrow, the new users will never remember the way things were just make it better.
Adena Nadler Notes:
I want to see their org chart, membership team is an interesting one, sounds like a pm/cs mix.
New feature & creation process
Involving users in conversations, a/b testing, active community, sounds like they're always changing the product and have low barrier for shipping to a test group and find out what's working or what's causing a reaction
Classic 'how can we improve onboarding' desire; Gave the product to folks who have never used it with onboarding and without onboarding to learn on the extremes to learn about what must be true
I like the desire to learn from folks outside their early adopters and direct market
There's a constant tension of quality and how it's measured, can be different for different teams.
ex. They ran a test where their research pointed them to a path and put it in the product and it didn't move the data at all. Should we ship it? Internally it feels better, externally it tests the same.
There are patterns where the experience is better but the learning curve is harder, can be worth it
Success can be removing something form the product
The quality they give up most on, is the technical quality, does it introduce bugs, is the code good, does it perform well, etc..
This person knows and abides by the company values in their work, every day.