i want to share a few thoughts on product iteration at TRMNL and "community driven development" came to mind as a good encapsulation. apparently this term is taken by folks in the city planning space, but today we’ll share it for the purpose of this post.

when tech founders (aka product managers) ponder what their platform should do and who it should serve, the starting point is usually a figment of their imagination.

in November 2023 i jumped out of the shower and shouted at my unsuspecting wife – "i have a new idea... Bloomberg Terminal for everything!" a few days later i started TRMNL.

over time that idea kernel becomes a vision, which in step grows with the momentum of feedback loops. on Black Friday i bought a Raspberry Pi and downloaded the Waveshare e-paper driver, leading to hours of confusion about how graphics are generated on a device. my lack of deeper technical knowledge led to "server generates image, device just displays it" logic, now dubbed as our pull architecture.

at some point the founder has a working product that does pretty much whatever they imagined. it’s a great feeling and one that most people reading this post have probably felt, as TRMNL is a community of builders.

but where do you go next? as you hire people and set goals, where do the macro (+ micro) ideas come from? how do you prioritize what to focus on next?

community driven development

at first glance this term may sound like the following:

1. ask customers what they want
2. build it

but in our experience that isn’t really true. we’ve rejected many, many feature requests, including the most popular (repeated) ones. for example:

• clock with < 1 minute refresh
• color e-ink panels (whoops, stay tuned)
• multiple sleep schedules

so no, community development is not a strategy to defer dreaming and enable laziness. rather it’s about providing the tools for the community to build things for themselves.

at TRMNL we found this groove in DX (developer experience). TRMNL team members make plugins, community hackers make plugins. we design layouts, the community designs layouts. we use dozens of API endpoints, the (BYOS) community needs dozens of endpoints.

thus developer happiness == customer happiness, so long as our customers are tech savvy.

expanding our audience

although we don’t have any venture capitalists, there’s always pressure to grow market share by appealing to other types of users. and indeed this has happened at TRMNL, just accidentally.

a typical customer relationship:

1. hears about us on a tech review / reddit post
2. gets a device
3. spouse sees it
4. device moves to common area of the home
5. plugin requirements change from Hacker News threads to family calendar
6. gets another device

we didn’t put any effort into achieving this flywheel, but we have made calendars and weather and other family-oriented plugins a lot better for this natural progression.

a few weeks ago we had an internal chat: should we aim for retail? should we be on the shelves at Costco, or fulfilled by Amazon?

in small batch experiments thus far, whenever TRMNL is sold through a retailer besides ourselves, customer support ticket volume and return requests are higher. this hurts team morale and makes me think we’re getting greedy.

so yeah, audience expansion "works." we’re just not interested.

speed == quality

in my 20s i was a full-time marketer and read 100s of books on consumer psychology, sales, persuasion and so on. from one of those books i recall a scientific study about 2 groups of people.

one group was asked to make some contraption, let’s say a box, 100 times within a few hours. the other group was instructed to spend the entire time making just 1 box.

at the end, the former group’s 100th box was better than the latter group’s 1st (last) box. this lesson has stuck with me in all my projects and is why at TRMNL we:

• push directly to master (sometimes)
• seldom require code reviews
• don’t have protected branches
• empower everyone to get involved in product, even if not their job title

if we made things for a mission-critical industry, say Aerospace, this would get us in a lot of trouble. but because we know our audience (hackers), it’s fine. not that i want bugs in prod, but because our community will help identify and fix them. ergo: community driven development.

thoughts on 2026

i put a few teasers in 2025 in review, but here are some other things i look forward to:

• thousands of published plugins
• at least 2x new products
• enterprise collaborations (including on-prem hosting support)
• IRL events at our Berlin warehouse
• open sourcing more of our secret sauce
• reducing prices (again)
• behind the scenes video content
• a 3rd warehouse where we make enclosures by-hand in the USA
• team retreat and live Town Hall (coming this March)

to the community reading this, keep your ideas and PRs coming. we’re on the same team.