Product philosophy and principles
While we use vision and strategy to guide what we work on, there are some common principles, which are built from our leadership principles, that define our behavior in building our product. These principles align the R&D team on the approach to product development and provide insight to our customers why we act the way we do.
We are Customer Obsessed. Working in an agile development process, we think of roadmapping and product development as living; subject to changes as our communities and customer needs change. The further out we commit, the harder it is for us to adapt to our customers’ needs. We use customer feedback to guide our product direction.
We Earn Trust. We welcome input from all members of the core staff and community. We appreciate input on the technical solution, user interface design, overall user experience and functional behavior of the product. This helps us uncover blind spots and promotes input and perspective of our customers.
We are Self-Aware and work on High Impact changes. We use data in our decision-making processes. By developing an MVP (minimum viable product) of a solution, we can gather more data to inform our future work; thereby allowing us to create solutions for real pains. A MVP may include providing a prototype or a partial solution so we can collect feedback in the most realistic scenarios. We try to ship the smallest thing as quickly as possible and learn from it, so we make sure what we are building is going to create the value expected by our customers.
We Insist on High Standards and have Ownership of the work we do.. This means we keep a high quality bar for our product. Each release we follow a thorough testing process that ensures each feature meets our design principles, is tested for happy path and edge cases and meets security best practices. If a new feature does not meet our quality bar, we will push it into a later release instead of risking creating issues and frustration for our customers. If we find out that there is an issue in a version of released software, we prioritize fixing it. We don’t shy away from dot releases, when a fix is critical to the usability of our product.
Last modified 7mo ago