Lessons learned: from consulting to building an app

[#1]

For more than ten years I worked as a consultant in the Atlassian ecosystem. My days were full of projects, helping companies customize Jira or Confluence, finding the right Marketplace apps, and making everything fit together.

I loved this work, but it had one characteristic: I was always in the background. Each solution was built for one company, sometimes very creative, but never visible to the wider community.

Why move from consulting to product?

Over time I saw the same challenges appear again and again:

• Teams using Confluence tables, but quickly hitting their limits.

• Customers exporting data to Excel just to do a sum or a filter.

• Managers wanting to see insights, but struggling with endless rows of data.

At some point, it was clear: these problems needed a simpler and more repeatable solution. That is how the idea of Simple Table started.

What I’ve learned so far

Building a product is not the same as delivering a project. Some of my lessons:

• Simplicity is hard. It is easier to add options than to keep the product clear and focused.

• Feedback is gold. Every support ticket, every post in the community, helps us improve.

• Community matters. By being active here, I learn faster than I ever could working alone with one customer.

Why it’s worth it

Even if product building has its challenges, I enjoy it deeply. When I see a team use Simple Table to organize their work better—and when I see it happen without me being in the room—I know it was the right choice.

It is still early days, and we have a lot to build, but the step from consulting to product has been the most valuable decision of my professional life.

To those of you in the ecosystem: have you also made a similar journey, from projects to products?

I’d love to hear your lessons too.

Enjoy!

— Mia Tamm

[Yong Yang]

Hi @Mia Tamm _Simpleasyty_ 

Great! It seems you forgot to add the marketplace listing link here 😊

Thanks for your post and here are mine:

I've created 4 Jira/Confluence cloud apps, all inspired by challenges I encountered while providing consulting services to my customers.

The pain points they address:

1. Sprint visibility – Teams lacked a single place to view all sprint data for a specific board or scrum team.
2. Real-time metrics – Lead time and cycle time weren't visible on Jira work items or Kanban boards until after completion, making it difficult to track work in progress.
3. Low adoption rates – Many customers invested in Jira & Confluence but struggled with adoption. A gamified approach to showcase which teams and individuals are actively collaborating could drive engagement.

I'd love to hear if others have faced similar challenges!

Thanks,

Yong, Forge5

[Mia Tamm _Simpleasyty_]

Hi @Yong Yang

Thanks so much for catching that I’ve just updated the post to include the Marketplace link!
Really appreciate you sharing your apps and the challenges they address, that’s super interesting to read.

Always great to connect with others building around real customer needs.

— Mia Tamm

[Jakub Nowak]

Hi @Mia Tamm _Simpleasyty_ really enjoyed reading this. I can totally relate to the shift from consulting to product work. That moment when you realize your impact can scale beyond a single client is powerful.

I especially liked what you said about simplicity and community; both are so easy to overlook but make all the difference. Thanks for sharing your journey and lessons learned!

[Laurent Van der Velde]

Loved this, @Mia Tamm _Simpleasyty_. Your post took me right back to my own leap from consulting into product, and how naïve I was about what it takes for an app to actually work in the wild.

In consulting I felt “done” when the client signed off. When I started my app, I thought the same rules applied: ship the feature list, celebrate, move on. Instead, I shipped v1 and… crickets. Not because the idea was bad, but because everything around the idea was fragile. Onboarding was unclear, the empty states were awkward, the pricing page asked people to commit before they knew what they were committing to, and my “clever” settings page was really a collection of decisions I was too scared to make.

What changed things was exactly what you highlight: simplicity, feedback, and community. I cut our settings by half and made one strong default. I replaced a three-step sign-up with a single field and let people play before paying. I started replying to every support email as if it were a user interview—screenshots, quick Looms, little fixes shipped the same day. One customer told me they kept exporting to Excel “just to sum a column.” That line became a north star. We added inline totals and tiny, obvious affordances. Churn dropped, not because we built more, but because we removed friction.

The hardest part wasn’t code—it was ego. Saying “no” to smart people, resisting “one more option,” and accepting that the version I loved wasn’t the version users needed. Another painful lesson: no feature is “done” until it’s discoverable. I learned to celebrate boring wins—better empty states, faster first value, a tooltip that prevents a question before it’s asked.

Community has been the cheat code. Sharing half-baked ideas, releasing behind feature flags, and letting early users co-author the roadmap made me build with less guesswork and more confidence. The day I saw a team adopt our app without me in the call felt just like you described: proof that the product could stand on its own legs.

So thank you for putting this journey into words. It’s reassuring to hear someone else say that simplicity is hard—and that it’s the right kind of hard. Here’s to more invisible polish, fewer toggles, and products that quietly help teams do their work better.

Cheers,
Laurent