Structuring teams and product development

My current view of product development comes from working as a developer, product manager, technical lead, and company founder. The details have changed between jobs, but the first question has stayed the same: what should we build? A team can write good software and still solve the wrong problem.

At Eebu, we built an ERP and other software for small and medium-sized businesses. I was the only developer on several products. We spent time on abstractions and premature optimization before we understood what customers needed. Being responsible for both the business and the code made that waste hard to ignore. I still prefer simple code that is easy to change while the problem is changing.

That experience also changed how I use feedback. Customers and domain experts know where their daily work is painful. Developers see the technical constraints. Product decisions need both views. Listening does not mean implementing every request. Feedback is evidence that the team weighs against its goals and what it has learned from other users.

At Woolman, I worked directly with customers on integration requirements and helped grow the development team to six people. As my role expanded, I spent more time on architecture, resourcing, and product work. That experience made the limits of a flat structure clear to me. Growth does not mean everyone needs every detail. Decisions need owners, and the people affected by them need a direct way to share information.

At Osgenic, my role combines technical leadership and product work. I guide technical and architectural decisions and work on backlog and roadmap priorities with customer and business value in mind. I also introduced regular one-to-one meetings with developers. An organization chart does not solve team communication. People need a direct way to raise concerns and understand why priorities change.

Technical choices also depend on the stage of the product. Before a product has found its use, I accept technical debt when it buys faster learning. The wrong solution will be discarded anyway. Once a system has real users and needs to keep working for years, the cost changes. Reliability and maintainability matter because failures create support work, manual corrections, and sometimes lost money.

My current preference is simple. Start with a close feedback loop and code that is easy to change. Give the team enough ownership to solve problems instead of only implementing tickets. As the product and organization grow, invest more in reliability and clear information flow. The process should change because the risks changed, not because a framework says so.