We founded Constructor to create a new kind of tracking tool, one that helps everyone on the team – developers, product managers, engineering managers, and designers – be more effective, more efficient, and more satisfied in their jobs.
In the words of one VP of Engineering, the tracking tool is “the beating heart of every software development team”. It’s where builders go to see what’s on their plate and what’s coming up, and where managers look to see how things are going. It’s where planning connects to execution. And it’s a crucial record of activity and decisions. But we think it can, and should be, much more – especially in an age of increasingly distributed teams when we can’t assume a shared physical space is helping keep everyone on the same page.
We envision a tool that’s a true partner in a software team’s success. One that operates like a smart, helpful assistant – getting users the information they need, when they need it; making reasonable inferences to eliminate drudgery; and trying hard to stay out of the way so they can do their best work. It’s a challenge we’re excited to tackle.
Our Product Principles
Seek and destroy complexity anywhere it exists
Complexity consumes the time and energy of our users and can occur in our product design, in user workarounds, or outside our product in other tools or processes. Simplicity doesn’t happen by itself, but only as the result of a sustained effort and a willingness to rip up something “good enough” to make it even simpler for our users.
Be helpful or stay out of the way
Users rightfully bridle when simpleminded software stands in the way of them getting work done. Our users are tech-savvy go-getters so we should trust them to be sensible and stay the hell out of their way. Think spell-check, not form validation.
Serve all roles well
Cross-functional teams are immensely popular and a proven way to build great software rapidly. Constructor needs to serve all roles on these teams well to avoid provoking tool schisms between developers, PMs, EMs, or designers.
Be malleable and process-neutral
There is no one "best process" for developing a software product. Different teams with different contexts will rationally adopt different processes. And every team’s process evolves over time. We have to make it easy for teams to try new things and evolve how they work, or they will rightly abandon us.
Pragmatism over precision in modeling the world
Since there’s no one right data model, it’s crucial to provide the right amount of model. People use our tool in myriad subtly different ways. With an insufficient model they’re left to figure out workarounds, but too complex a model will add overhead to common operations.
Offer lightweight, flexible solutions
Our users want to build great software as quickly as possible. Since Constructor is the medium in which their development process is embodied, we need to offer lightweight solutions and make them the default so they can minimize the hoops they have to jump through to do their work.
Seth Purcell has been leading software teams at startups for over fifteen years, and was most recently the CTO of Signpost, a marketing software company in NYC. Seth has been programming and designing user interfaces since the 90’s and is equally passionate about software engineering management. Seth studied Aero/Astro at MIT.
Andrew Kallem has pursued software engineering since childhood, including web, mobile, and game development. Most recently he was an engineering team lead at Signpost. He has also led technology projects at Goldman Sachs and McKinsey. Andrew studied Economics at Harvard and Computer Science at Columbia.