Over the past few months at Squads, we’ve been working hard on our Startup Development as a Service platform, Capacitor. There, we allow teams to evolve and clients to book capacity with teams online. Of course, we could not miss the opportunity for all sorts of interesting experiments on this project. Some we deemed too risky to implement for client projects. I will share some lessons learned in this post, and perhaps more in the future. Most things we tried are based on well-known practices, combined in a particular way.

Pay for Working Software

At the beginning of the project, we made a conscious decision to not spend effort on design and dive straight into functionality. I wanted to see if a product can evolve without any up-front formal design. Some design happened via developers, of course, and the platform doesn’t look entirely undesigned, but the lack of a designer’s hand is visible to users (sometimes painfully).

Last week, for the first time in months, I engaged with our best designers to start turning this around. This brings an interesting struggle to the surface. In conversations with our designers, as a product owner, I pushed for design decisions to be taken in our weekly iterations. I don’t want to pay for Photoshop mockups, I want to pay for working software.

However, developers work more effectively when tasks are accompanied by design. I want weekly iterations that push me into a position where I either have to accept rework (because the design is invented after some work was already done), or I have to accept that I’ll have only a PSD at the end of an iteration. Also, I want tests, including regression tests run before a feature goes live. If we have one day of design and one day of testing in an iteration, that leaves only three days to develop.

Find Solutions in Contradictions

At Squads, we strongly believe that the best solutions are born from a contradiction, or friction that someone experiences. The contradiction here is that development needs design upfront, but the design can only be finished when a feature is proven to work for the business (i.e. live). Design cannot finish without development, development cannot proceed without design.

How can I have my cake and eat it too? We decided to change the way we work. Designers sketch features with developers, then developers work on the feature, focusing on functionality first. During development, designers collaborate with developers, to ensure design decisions can be taken in the browser, not necessarily in Photoshop. When a feature is ready to be released, it is likely not in its final form.

The final form is decided based on the production feedback we measure after the feature’s first release. This way, parts of the product follow the same lean lifecycle as the product and the company around it. We make everything iterative. This pulls many involved parties out of their comfort zones, which increases learning and adaptability. It also introduces new risks, so each feature in each release needs its own risk/reward analysis. This analysis is done by the product owner with the team, prior to each release.

All development processes and tools assume a linear flow from idea to live. Iterative processes let many changes go through that flow with iterative schedules, so learning happens as a feedback loop. Decreasing the lead time from idea to live increases the impact of feedback. Ideally, a change should be triggered by a live user. Ultimately, I would love to see a user ask for help while using the application, with the desired change happening in their session, giving them instant gratification. This requires fundamental changes to tooling as well as processes, but I’m very happy with the improvement we’ve managed so far. An entirely new idea can be live within a week after conception, even if design input is needed.

It seems that instead of being assembled like a puzzle, the product comes into focus like a progressive jpeg. Getting to the final result takes more time than it theoretically would when assembling the puzzle from up-front design, but businesses can already adapt to the product during the process. That means this strategy if balanced well can lead to a success-or-failure decision more quickly. I’m confident that the forces shaping these processes will allow us to iterate daily, and even faster in the not-so-distant future. More experiments will follow.