It heavily depends on what you refer as estimates. If I have a new client, they have an idea and a budget. They definitely need an estimate. However, it's not the estimate we, devs, immediately have in mind, like knowing exactly the amount of days for each specific feature. They need just a ballpark, a range, an idea for their product. For someone who has no idea about programming it's very hard to convert a budget into something more tangible. And it's fair. It's also part of our job as devs.
Some clients have hard discussions with investors, they need a product team with them to provide the necessary info. They might have deadlines. And we need to be able to master the scope, cut some corners if necessary, make use of 3rd party services to create workarounds and deliver value as soon as possible.
That's what we, Whitesmith.co do as a product studio. After the idea is aligned, we define the MVP or the PoC and we make the best we can with that budget (if possible and doable). We rollout the product, we gain traction, we get more funding, we keep developing in an agile way, always validating every step.
Essentially, we make sure we deliver the necessary value according to the needs of our clients. That's way different than implementing features within an estimate, because I agree with you on that. If there's no other way around, the feature should take the time it takes. Won't argue with that. But then we ask ourselves again, can we deliver value sooner?
Estimates are tricky. They are data points, they have different levels of precision, different levels of importance depending on the context and the business. If you work on a single product estimates will have different purposes from consulting. An even on consulting, their purpose changes a lot depending on the phase we are working on. We can easily estimate things that we know and things we know that we don't know. But what about those which we don't know that we don't know? That's when estimates really fail.
Putting everything in the same basket is a simplistic view of something highly complex as estimates.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It heavily depends on what you refer as estimates. If I have a new client, they have an idea and a budget. They definitely need an estimate. However, it's not the estimate we, devs, immediately have in mind, like knowing exactly the amount of days for each specific feature. They need just a ballpark, a range, an idea for their product. For someone who has no idea about programming it's very hard to convert a budget into something more tangible. And it's fair. It's also part of our job as devs.
Some clients have hard discussions with investors, they need a product team with them to provide the necessary info. They might have deadlines. And we need to be able to master the scope, cut some corners if necessary, make use of 3rd party services to create workarounds and deliver value as soon as possible.
That's what we, Whitesmith.co do as a product studio. After the idea is aligned, we define the MVP or the PoC and we make the best we can with that budget (if possible and doable). We rollout the product, we gain traction, we get more funding, we keep developing in an agile way, always validating every step.
Essentially, we make sure we deliver the necessary value according to the needs of our clients. That's way different than implementing features within an estimate, because I agree with you on that. If there's no other way around, the feature should take the time it takes. Won't argue with that. But then we ask ourselves again, can we deliver value sooner?
Estimates are tricky. They are data points, they have different levels of precision, different levels of importance depending on the context and the business. If you work on a single product estimates will have different purposes from consulting. An even on consulting, their purpose changes a lot depending on the phase we are working on. We can easily estimate things that we know and things we know that we don't know. But what about those which we don't know that we don't know? That's when estimates really fail.
Putting everything in the same basket is a simplistic view of something highly complex as estimates.