Why our startup is selling services(blog.davejafari.com)
blog.davejafari.com
Why our startup is selling services
http://blog.davejafari.com/why-were-selling-services
5 comments
It sounds like your curious on how to manage both a client and an internal project. I'll be happy to share our experiences doing so later. The simple explanation is to have a good understanding of your development velocity, treat each project the same in resource allocation, and set expectations for both your team and your client.
In our case, we have more time-flexibility in our current client project as it was done on a fixed-price bid. We're also at different stages of each project: one is firmly in implementation and the other is in leaving initial research and starting into business model iterations via customer development.
In our case, we have more time-flexibility in our current client project as it was done on a fixed-price bid. We're also at different stages of each project: one is firmly in implementation and the other is in leaving initial research and starting into business model iterations via customer development.
I've been doing consulting for a while. Not only on software, but on other industries.
I'm curious about your whole experience. It seems that you are a bunch of smart people cooking up an awesome startup. That's why I want to read more.
You mention doing a fixed-price bid project. Could you expand on that?
I'm curious about your whole experience. It seems that you are a bunch of smart people cooking up an awesome startup. That's why I want to read more.
You mention doing a fixed-price bid project. Could you expand on that?
I don't really adhere to the fixed vs variable pricing schemes too strongly, they are just trade-offs. In fixed-price, we're taking much of the implementation risk onto ourselves. In exchange, we ask for a stringent requirements phase and a little flexibility on delivery dates from our client.
Our sprints are basically at 2/3rds utilization and we've reserved the right to take a couple off-weeks between sprints over the course of a 4 month project. This gives us some strategic leverage in picking up attractive small projects so we don't have to completely close up. It also gives us the opportunity to do full sprints on our own product if our MVP tests, developed during the 2/3rd sprints, look good.
That being said, flexibility does not mean half-assed. We're doing our best work whether it be for our clients or our customers.
Our sprints are basically at 2/3rds utilization and we've reserved the right to take a couple off-weeks between sprints over the course of a 4 month project. This gives us some strategic leverage in picking up attractive small projects so we don't have to completely close up. It also gives us the opportunity to do full sprints on our own product if our MVP tests, developed during the 2/3rd sprints, look good.
That being said, flexibility does not mean half-assed. We're doing our best work whether it be for our clients or our customers.
We were doing this for 9 years. The secret is to have part of the team serving customers and the other building products and experimenting. Also real customers are a source of good ideas.
Also real customers are a source of good ideas.
Great point. Getting the problem to fix straight from the source is ideal. Do you have any examples of how you have used that to your advantage?
Great point. Getting the problem to fix straight from the source is ideal. Do you have any examples of how you have used that to your advantage?
Yes. Can discuss it privately. Please send me your e-mail in the contact page of http://www.databigbang.com/#contact
I like this article, but an important word that's missing from it is "demand". Consulting allows you to keep an eye on what the market wants.
On the flip side, building a product allows you, potentially, to deliver something that people don't even realize, yet, that they want.
Putting the two together: If you can abstract concepts from their material demands while delivering their material demands, you get paid to produce something that they want now and to learn what they might want that they don't even realize.
On the flip side, building a product allows you, potentially, to deliver something that people don't even realize, yet, that they want.
Putting the two together: If you can abstract concepts from their material demands while delivering their material demands, you get paid to produce something that they want now and to learn what they might want that they don't even realize.
Exactly. The approach that my current employer used (that worked really well) was to start with consulting, find out what customers valued the most, and turn that into a product. This way they were profitable from day 1 and had absolute proof that the product would be successful before writing a line of code-pretty damn smart if you ask me.
[deleted]
i think it's great in theory, and it can work.
It just takes a lot more self control. It's too easy for the consulting side to take over, and it requires an iron will to prioritize that doesn't pay over work that does.
It just takes a lot more self control. It's too easy for the consulting side to take over, and it requires an iron will to prioritize that doesn't pay over work that does.
Also, consulting brings a host of other problems. Managing time is a tough one. Unless one is a circus juggler, switching between projects is almost impossible. Plus people tend to push back their MVP to keep a client happy.
Anyhow, just write a bit more.