So we’ve been doing some client work at Firmhouse and we love it. We love it because it’s a good learning school. You get involved in projects you normally wouldn’t be involved in. You experience how other companies work at a fairly close distance.
But today I want to write a bit how we, as a bootstrapping company, effectively are bootstrapping with client work. Our vision was to bootstrap with our own products, but as it turns out this is quite hard. So we’ve been actively searching for how we can effectively combine client work with our own projects. A way in which we can build and test our products without outside funding(s).
Our approach to client work is to be ‘product oriented’ instead of ‘project oriented’. When we first meet with a client we directly start scoping the product, not the project. We do this because they’re not asking us to build a solution for them, they’re asking you to build a solution for their customers or users.
Point your vision from delivering a client project to deliver value to their users. As a web company working for clients you’ll experience that a client never has a correct articulated end result. End results always evolve. It’s this change that’s ‘evil’ in most project management methods. That’s because the process isn’t created to accommodate it. When clients request changes, it probably is because they’re learning more about the end-user and how they can capture the value of the product. It’s just the people that pay your bills being concerned that their product is of value to their end-users.
And so you should be concerned too.
Let go of the illusion that you’ll ‘do’ a few clients for a couple of months and then start building your awesome product for a few months. Make your own products and client products work together. You’ll have periods in which you can observe how your product is being used. You’ll have times in which you need to regain focus and need to think outside the box to come up with creative solutions. So why not think in the box of someone else, it’s outside you’re box and you can make some money.
We do this by working in timeboxes. We plan all of our work in timeboxes of two or three weeks (changes over time). We tend not to look further than 1-2 timeboxes. This comes from experience, within those two timeboxes we can deliver two or more working software updates to a client. These updates always instantly create change in which we can accommodate by not planning to far ahead. What if a client requires us to give a fixed end result? We commit to deliver a working product for end users by a certain date.
My advice for starting web companies that want to bootstrap:
- Deliver on products, not projects. Dig into your clients questions and start scoping the product. Working products deliver user value (equals the happiness factor of the people paying you).
- Release early and often. There is no such thing as building off site for 4 months and perfectly deliver something that (fully) satisfies users. If your client doesn’t accept your product, there is no payday. Where there is no payday, there is no money for the months planned to build your product and your back to scratch again.
- Take your lessons learned while building your own products to your client products. Explain a customer the concept of ‘Continuous Deployment‘. We like to push quick updates to the live versions of our client products. Imagine a user asking for a real small and feature.After validating what the client and his users want, push it an hour later to their product. They’ll be blown away. I can assure that there aren’t that much big web companies out there that will do the same.
- Work for the love of products. You need a minimum cash-flow that barely keeps the lights on. This gives you advantages like not developing big spending patterns and being able to easily switch to living from your own products when they’re ‘ramen profitable‘.
I’m looking forward to hear from other startups bootstrapping this way. We’re developing a model for this kind of startups which I will blog about more often from now on.
[...] This post was mentioned on Twitter by Robbert van Geldrop, Robbert van Geldrop, Bob Jansen, Simon Vreeman, Simon Vreeman and others. Simon Vreeman said: RT @jansn: New blog post: 'how to bootstrap your startup with client work, but not become a consulting company' http://bit.ly/bCO8tp #bootstrapping [...]
Nice post, but you aren’t paying much attention to the “not becoming a consultancy company” part.
Cash from client work is great (we do some too), but it can create a safezone for your failing start-up concepts. So when do you decide to kill your darlings?
Another thing is that clients have your phonenumber and a lot of questions. You will need to answer those to get paid and keep them happy. But your start-up doesn’t call you at random times to ask if you could work on that cool new feature.
I’m not sure if this is a good way to fund the road to ‘ramen profitability’, I tend to say no. But it’s an interesting topic for those who want to keep investors away.
Thanks for your comment.
I agree that ‘the not becoming a consultancy company’ needs a bit more attention. Let me elaborate a bit.
Of course your clients will be calling you to pay attention to their project. But the real feedback comes from their users. We try to steer our client products based on that feedback, just as we do with our own products.
The hard part in running a company with client work and your own products is that they always have evolving questions, as do your own products. But the pain is within the processes being really different. That’s why we aim to keep the processes really close.
We’re agile and plan in timeboxes. At the start of a timebox we plan both updates for client products as well our own products for coming two weeks. By thinking in end users requirements allows us to focus on product development.
I think one of the possible success factors we’re starting to experience, is that there is a dedicated product owner who is the filter to the team. We’re making sure that the team internally isn’t in direct contact with the client (at some points they might have direct contact with users for quick feedback).
Let me blog about it next week because I think your comment holds some good points. Going to take some time to think about it.
Compliments on the fact you’re blogging openly on this Bob, some small notes from my side based upon my little knowledge and experiences regarding your advice for startups:
1. Deliver on products, not projects.
From your perspective absolutely yes but the first customer paying you is probably looking for a luxurious custom made suit at the price of a chinese lowcost manufacturer…
2. Release early and often.
I think this does not match with each client, it’s a vision on matters that has to align with your customer’s DNA.
3. Take your lessons learned while building your own products to your client products.
This implicates your communication skills need to be extremely well and your management of expectations too. Through the process there might be a situation where you recall things that were earlier said and it might damage you’re credibility….
4. Work for the love of products.
Hear hear, this separates you from a golddigger or a winner ;-) and remember that only true winners find gold!
@ayman you know we love to be open.
Regarding your points.
1. True. But unless a person is the only user of a piece of websoftware, you’ll want to involve knowledge about the other users. It’s not that you don’t listen to the persons paying you, but you need to help them to build a better solution for their users than they’re asking you for.
2. Not all customers think this is interesting. But in terms of process it’s not that bad to keep on short release cycles, it can be a short check for internal purposes. It’s taking the conversation from paper-based prototypes to working software. Which always is a big leap in software building. You’re point is on the spot though, we’ve experience customers that won’t their employees or users bothered too much with testing and feedback sessions.
3. Solid point and this is one of the points in which we experience(d) a lot of pressure from customers. This point was mainly about new techniques and process improvements. Our expectations with running solely on client projects is that innovation in terms of process need to be done outside their projects.
Basic point here, we experiment with customer development and continuous deployment. This triggers a certain growing knowledge towards using metrics for improving products. Which really we help our feature client projects to evolve faster.
4. So true. Maybe it should have stated: Work for the love of GOOD products ;-). But hey, that’s a no-brainer.