Cause of a Kind: Agile Product Development

Who should NOT use Cause of a Kind...

This is a tough question to answer as a business owner. You start off pretty much doing all the things, but after a number of years at this we have a pretty good idea of bad fits for us. Here's my top three, but I encourage everyone to try to answer this question for their own business.

1. You're looking for pure execution. There's plenty of dev shops out there that focus purely on executing a spec or designs. It used to be called PSD to HTML shops but now it's usually Figma to React or some other js framework. We're a product development shop, and part of our magic is being in the trenches doing design, research and dev with our clients. If you're looking for developers to just execute a spec or instructions, that's not us.

2. You want the classical agency waterfall process. I've worked at many agencies before and the fairly standard process goes something like this. We do discovery, followed by a lengthy UX design phase with some predetermined (usually 2) rounds of revisions, followed by a black box dev process where something comes out the other side that is ideally "pixel perfect" to the designs. In our experience this process never works. The outcome is often full of things the design process missed (error states, odd user behaviors, features that missed the mark) and ultimately client and agency go back and forth trying to make it right until someone says uncle. We practice agile here, design and development happen together here with no black boxes or big reveals. You'll see how the sausage is made in real time and we never limit number of revisions. We release early and often and each iteration is a chance to pivot from a faulty or incomplete assumption.

3. You want an outsourced solution. While we have employees that live all over the world, they all are a part of the Cause of a Kind team, learning and collaborating with each other. We don't outsource to other agencies ever and our clients can have direct contact with any designer or developer working on their project. There's less layers of indirection and no games of telephone. But what about scope creep? We don't believe in it. If the scope must change it's because we learned something in the last iteration that disproved our assumptions. We don't just drive the car off a cliff because we agreed to a predetermined spec based on old assumptions. You hire us, you're one of us.

These are my top three reasons to choose the other guys. But if you’re looking to get in deep and do the hard work of developing a product through learning and iteration, we should be your first call.