5 product development lessons I learned from refitting an abandoned sailboat

The last few months I’ve spent on a project to bring an abandoned sailboat back to life, and though the project is far from finished there are some lessons I want to share here.

1.) Limit WIP, but only as far as you can

There are so many things broken that despite my desire to use single piece flow, its simply not practical. That being said, you can limit WIP when you actively think about it. I tried breaking down the work per room / layer / functionality so that we could actually progress. It is great to see that the bedroom was done rather quickly, that is good for the soul. However at any time there were always 4–6 things in progress. Things like painting a pannel, running wires, reading up on regulations, sanding the hull etc. Visualising helps.

Yikes, a WIP of 7 and I only know the order of the top of the backlog

2.) There are layers upon layers

Building physical products looks easy but there are many things to discover. For example, I changed the kitchen fully finished kitchen design after a sailing trip to the UK with friends. The smell of freshly baked bread at 5 in the morning is pure value. It seemed easy to switch to a gas oven, but then I discovered there are many rules that you need to think about and the design kept iterating as old sailing boats are not really prepared for the new rules. Turns out it is nearly impossible to think of everything upfront if you have never done it before, you need to actually start building and researching at the same time.

3.) Team motivation is hard

“It is going to be great! Lets all do this together” I was really enthusiastic about the project and ignorantly assumed my family would be too. Even when they nodded, it didn’t mean they were _that_ invested in it. To my surprise it was not that easy to keep everybody engaged and motivated, especially since lots of the tasks are not that much fun. Finding out what they like to do and celebrating successes proved to be equally important as doing the work.

In the end the whole family helped out, which made me proud

4.) Milestones exist

Taking an agile approach, some things can always happen the next iteration. But there are also some things that have semi-hard deadlines. For example painting the hull must happen in a temperature range of 15–20 degrees, <70% humidity, cloudy and no rain. This is a slippery window and it gets harder as the summer comes to an end. Missing the window will shift the project to April…. And many things are depended on the paint. There’s ways to influence it but not too many.

Shiny new interior, I wonder what all the cables do?

5.) Specialists speed things up

Cross functional teams rule! A team should have all the skills to get that increment out of the door. It’s my mantra in business, and yet….. There are so many skills that this team (ahem, me) needs to develop that it makes sense to hire specialists to speed up certain areas and limit the risks. I hired a guy to help me with the engine, not because I can’t do the work, but because every time I fixed my motorcycle engine I would end up with some left over parts and no idea where to put them. We do pair up though, so I am learning the tricks of the trade and move really really fast.

In conclusion

There you have it, four lessons I stumbled upon that I hope will help you building your product. If your product is more software dominant, these will still hold up:

1. Limit WIP, but only as far as makes sense
2. Combine discovery and delivery, it is easy to overanalyse
3. Just because you are enthusiastic, doesn't mean your team is
4. Milestones are real, how and what is flexible
5. Don’t be afraid to hire specialists (but learn from them)