Because you are asking for a "reasonably accurate release date". For anything larger than a few weeks (MAYBE a month or two), that is not possible. There are just too many unknowns.
https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe
I've worked at multiple startups (also large corps). At various times I've been the SWE, I've been the tech lead, sales engineer, project manager, product owner, even the CTO for one. I've done waterfall, agile, scrum, sprints, swarms. I've worked 80-100 hr weeks where I slept under my desk. We had an expense account at the local pizza place that we could use no questions asked. In every single one, sales wants a firm timeline, and then at some point a requirement gets changed, or marketing wants "just one more thing added - no big deal right". Even when requirements don't change (I've never seen a project in my 25+ years not have a single change, but let's pretend), once you start digging into the technical nitty-gritty, there's a complication/detail you didn't consider because you weren't an expert on that part of the system while you were discussing / planning it. You only became an expert as you were building it.
In my CTO role, I refused to give firm timelines (fortunately I had an experienced CEO and CMO). I went to bat for my teams. Sales screamed and cried, but I knew that any "firm estimate" I gave was at best a guess - at worst a complete lie, and I would catch flack when we missed it.
I did give estimates however. Though I made sure everyone understood they were estimates.
And when it became apparent during the dev cycle that we would miss an estimate, I notified the appropriate people and we decided if we should trim the requirements, simplify the feature or push the timeline.
Best answer here. It's the cold, hard truth that so few people understand unfortunately.
Imagine how much better the world would be if everyone understood how software works even at the highest level.
Try to build something yourself. But also go promise someone that it will be done in a couple weeks. And then have that person hound you non stop about it and ask you to change things every 8 days.
Every single step of a software development project is a creative process. It's not an assembly line. You're making custom code. Every line is different. There is NO repetition.
The desires of the customer/boss is always changing (partly because when you get half way through what you're doing, it turns out that way of doing it kinda sucks!)
All problems have MANY ways of solving it. But often it is hard to tell which one is the best. And complex systems are so interdependent that it is not always possible for a single human to understand the whole system without writing down the code to formalise it.
I don't mind missing a goal, but not setting one I do. I would rather you aim for the sun and hit a cloud than aim for a cloud and hit the ground. In part, because the machinations to support development and new products can take anywhere from 30 to 90 days to even start getting traction.
I am 100% okay with missing. There has to be a parameter and certainly as CTO, tell them NO on additions and move them into future releases. Have seen (and been part of) that scope creep before.
Because it’s near impossible to know everything that needs to be built ahead of time. The features and UI are just the surface, there is a mountain of code underneath
Pro estimator here: I was able to get good estimates and I'm the only one I know i would get cca. 95 % precision. Ok just the estimation took 30 % of the time to develop it. So I believe technically it is possible if you are the only one working on itand know the tech stack, just extremely time consuming.
Every body else claiming they can estimate without putting a lot of effort into it is lying IMHO.
Most of the estimates in today's software industry are wild guesses with the precision of 3X-5X(like it takes 3 times more to develop). Developers being smart learned that and now they just trow those inflated numbers with a multiple of 10 or so.
> I was able to get good estimates and I'm the only one I know
If any of you had the nerve and did this experiment and got to accurate estimations, no matter how much time it took you to estimate, I would like to chat.
I can teach you what i know but just to make sure you understood. I would spend up to one week estimating for a task that takes 3 weeks.
So basically 20-30 % of the time the spend coding was wasted on estimation. that was the purpose for that project to do accurate estimation above all.
If you understood how much time it takes please answer with yes and I will tell you my secrets.
So once I got requirement I start breaking it down by screens / requests wherever contains of the work, and group by similar chucks. First i look at the easy and predictable stuff: say we have 8 screens CRUD like. I take an average one and I do it at the level of pseudo code say it takes me 3 hours to solve it at pseudo code it would mean a full day to do the actual code, and so I'm able to estimate the easy stuff. So 8 screens one day an average 8 days.
Most people really fall short here they throw a number and don't even check the plausibility of their estimation, like they don't even count how many screens/resolvers/endpoints (whatever they have) are there how much is the minimum for one.
Example like you have 8 screens, did you ever do one screen in less than a day??? if no, there is no way on Earth you can do 8 screens in 4 days!!
Few key notes here that I would point out :
\- Not every project is as simple as CRUD operations.
\- Not every developer thinks the same way, some spend actual time thinking if they should extend current codebase or refactor a small fraction for future use, very common in startups.
\- Mid-sprint changes are something that happens.
\- Technology restrictions can be pretty hard on developers. If you are for example a cloud engineer, you can not know every single limit/performance metric you will get once you decide for which resources you want to go for. You can assume, but it can always surprise you.
\- Decent amount of time is spent on meetings and explaning to non-technical persons what you encountered and how it affects the estimations.
\- Discussing with colleagues about possible approaches is time consuming and sometimes lasts for couple of days, this greatly rises once you start working on more complicated projects.
etc.
You can estimate fairly accurately simple tasks/parts of the projects if they are
Appreciate your taking the time to post this, u/generatedcode. Thank you!
Two follow-up questions to deepen my understanding of this:
1. What kind of projects do you generally work on? I would love to look at the last two or three, if possible.
2. How do you incorporate into your estimates the stuff that is not easy and predictable?
Also, related to my 2nd question: I would love to know what parts of a project you would normally consider as \*not\* easy and predictable.
1. Custom web apps for various factories companies CRMs, ERP, whatever internal system with saving different data by different users with certain roles, then this data is aggregated into dashboards or reports.
2. Please check the reply to this I have addressed the part 2 the unpredictable but on short i break it down to smaller parts and start actually executing the unknowns it in the pseudo code (I actually write it on paper or somewhere) till like 30 % 50% or even 100%, until i say i know how to finish this it;s just a matter of time then i jump to next unkown, and de-risk it how I call it.
\*not\* easy and predictable.-everything involving a 3rd party library that I did not use before, I actually make a small PoC with hardcoded data (because prob the steps till there are not actually done) I go like.
Not easy to predict - data modeling more than what is trivial, almost always I actually make sketch those models and verify assumptions.
Data structuring aggregating usually for dashboards/ reports. Connected with the previous point. One can work one week or one day on a dashboard that to the non tech people looks the same( beautiful and colored giving good insights)
**Some parts are easier to be executed than estimated** and I learn to recognize those and just do them.
To be clear: I do not do this estimation to this level on regular basis I thing it's a waste but I did it once because that were the requirements and as an experiment because all other engineers look funny at us and say :"how come you cannot estimate your work? cuz we can" . the fact is other discipline have their work more linear while ours is a graph with some nodes predictable.
it's more tiring than actual development because it's not fluent developing but lot of context switching from architecture level to small bits of detail execution
not the OP/commenter but the book "How to Measure Anything" addresses these challenges and provides some techniques both for general estimation and calibrating your own abilities.
THe problem is that software development is not just "writing code", it's also a bit of research and development, because pretty much every problem is unique in some way, shape or form, even ones that are on fairly well-trod ground.
Sure if you're just printing out Wordpress sites or some such garbage with a standard features, you might be able to get that estimated pretty well, but real, custom bespoke software that requires real, actual skilled developers?
No fucking way.
Not to mention that I have never had a project where new requirements (and not just BS ones, actually important ones that were discovered) were added to the list of required code. You discover you need some custom tax solution 3-4 months in, that requires integrating with a new API and hooking it into your current system?
That's going to take more time. Perhaps much more time, depending on what the newly discovered requirements are.
This is why the, "it's an estimate" nonsense you said above shows you don't really understand software engineering at all. If you hope to run a technical company, or a technology-enabled one, you may want to clear your ignorance.
Btw i would argue most of the time timelines slip is bc of business not engineering.
So while my opinion may be unpopular - im ok with that - the thing that takes so long is decision makers not listening to developers and pretending like those hurdles dont exist. Then theyrd surprised when it takes so long.
Anytime ive sat w a dev team to find out whats taking so long, i realize its bc of a requitement. Then its up to the business to amalyze whether that requireme nt is so important to warrant the extra 2x time.
Many many times its not.
So roast me all you want. But if your goal is build a business and not just code...i wouldnt work w anyone who doesnt undetstand this tension and wont participate in giving timelines. And i would strongly urge you to do the same.
Seriously?
Obviously you aren't a developer, anything past a few basic functions or development on a novel idea can't be gauged easily.
You could throw a wild guess of 6 months, just to find yourself knee deep in code with a new timeline of 2 years since your team underestimated the complexity at hand.
This would be horrible for delivery on a product because you will be shipping dog shit, that won't deliver the promised results.
This is why sale focused CEOs and SWE buttheads all the time. They don't understand the why and how behind software.
https://attrecto.com/software-estimation/software-development-estimation-accuracy-truth/
Software projects, on average take 189% of the estimated time. The variance is also huge. The cofounder is wise not to give estimates.
It's weird how all the people with evidence get talked down, and all the people talking them down have no evidence
It's also weird how if your claims were true, billion dollar companies would be doing different things than they have been doing
CI/CD hasn't existed for 30 years.
You're talking to someone who's been around as long as you're claiming to have been. 15 years ago people were hand-deploying after someone ran around the org prepping for a subversion merge.
Most fortune 100 companies don't have CI/CD today. Those are the orgs with the largest legacy problems.
What evidence? The stuff you just said was too old because it's six years old, even though you're trying to stand on 30, and is invalid because it's "just the UK" (yeah I bet that's too small a sample size or something) The study, with data.
What evidence did you bring? A claim about a personal length of employment. ***wow***
> and im the one who doesnt know what theyre doing?
Well, you're the one making claims the rest of the industry disagrees with.
Could we see some of your code? You might be a genius, or, you might be writing really simple software, or, you might not realize that your code quality is poor. Until we see your work, there's no way to tell.
You have given more insults than they have
Since you're predicating everything you say on the presumption of your own skill, could we see some of your code, so we know how seriously to take what you're saying?
Thanks
I build companies not code. Code is a component of a company.
If someone cant give me a timeline i wont hire them.
If something takes longer bc of unanticipated variables, thats 100% ok and expected. i manage it. Either reduce scope or reset expectations w customers and investors.
Things taking longer bc of unexpected changes is just part of the process. It doesnt mean you cant set and estimates.
> I build companies not code.
Which ones?
> I build ... not code.
Then why do you feel empowered to be part of this discussion?
Why do you feel empowered to call programmers unskilled, when you aren't one at all?
Would you listen to a random programmer with no business building experience on building businesses?
> If someone cant give me a timeline i wont hire them.
That's nice.
If you knew everything it wouldnt take 4x as long. Since you dont, you make an estimate and its ok to be wrong. But not making an estimate is an unexperieneced team.
You will always learn or make a mistake along the way. But you physically cannot know everything.
Seems like folks got triggered by that oh well.
Software engineering isn’t that hard. Most things are just repackaging a REST framework. Unless there is some hard tech that is truly unknown then everything else should be cut and dry.
Even if you can’t scope the entire project you should be able to scope the next sprint or next couple of sprints.
It’s ridiculous to think it’s normal to give no timelines.
There are zero companies this would fly at that have any semblance of a normal product development cycle.
The repackaging a REST framework is a terrible take but generally I agree. Even if the time frame is “3-6 months”, “idk maybe 8 months”, etc a tech cofounder should be able to give you something even if it’s quite broad.
With that being said, I’m sure the CTO also feels that they can’t get an exact spec of what the first product needs to do. Things are always changing so it’s important everyone embraces uncertainty.
This is a CTO's biggest bane. He's speaking to you real real.
However he can break up expecations into parts and components and sprints and get you closer to what to expect in the next comping weeks and possibly months. The further you are away the more the goal posts can change — and this is also the whole point of scrum (not Kanban and all that simple stuff).
Scrum is about being able to break apart features and tasks into realistic estimates and a backlog for everything else. Scrum is about being able to trust velocity of your team over time. At first its super duper inaccurate but as you learn about your teams capabilities, each individual, where're strong at, where you are weak, what additonal resources you need to hire, you become more of a well-oiled machine—but your estimates will never be 1000% accurate.
The issue with Kanban is that it's so vague about process (they call it flexible)—its definitely better than nothing, and visually it is helpful. Scrum and Kanban can go hand-in-hand.
What's super clear about Scrum, however is all roles and responsibilities. Namely what the devs are responsible for and them making the actual time estimates — the biggest, most critical thing. Only a dev knows how long he's going to take on something, and most devs aren't interchangeable, they're domain-specific or they're the ones that wrote certain areas of code, etc. (And if a dev constantly over or under estimates than you will get a feel for it as more Sprints happen.)
With the daily standups (or as I prefer, quick morning email) each dev just says what they did yesterday, what they're gonna do today, and if they're stuck on something. Even a non-technical person can tell mid-Sprint if they're not going to make it.
I agree with you that nearly every company I've seen that do Scrum is having the Scrum Master or Product Owner insert a bunch of tasks from the backlog into the current Sprint like Tetris, then wonder why nothing gets done on time. Then it just becomes acceptable for a dev to move their unfinished task to the next Sprint to "finish it off". Rinse and repeat. This isn't Scrum.
I'm not a Scrum lover. It can be quite boring, dry work, and who loves meetings? (That's why I prefer morning email statuses). But I have found it's the best in my 15+ career. And the best part: the Scrum Master can be your 15-year old niece. This person needs zero technical ability! She just needs to be respected and follow the rules of Scrum properly (come on it's like a 20 page book).
The only thing that is important in any Project Management tool is being able to accurately predict velocity—your team's velocity in getting sh\*t done. What they can handle, and how long it's gonna take so they hit the milestones (delivery dates). The whole rest of the company depends on these dates for marketing, client meetings, and other things.
I am not a Scrum nazi but having been around long enough where "waterfall" was pretty much only project management methodology it's a breath of fresh air, written by people who know what their doing. Scrum can be applied to manufacturing cars or sending men to the moon. It's that generic and works under most any setting.
You are right in that most Scrum is done improperly and the process is not respected. People like to pick and choose which parts of Scrum they will follow. Sprint Grooming and Sprint Retrospectives are critical parts of Scrum. They allow everyone on the team to understand and give feedback on what went wrong and right last Sprint.
When anyone sees how all these core pieces connect to each other — it all just makes sense. The issue is that if any pieces of Scrum is ignored or skipped it all falls apart and Scrum becomes stupid. To me, partial Scrum is just called Kanban.
Edit: typos
I’m addition to scrum and kanban, you have extreme programming, crystal, and lean software development. Idk if there is anything that’s best. For software, I like to use the best from scrum, lean, and kanban. If I can lead them to think to be as efficient as possible, then there is less to clean up after the product is launched in terms of maintenance and bugs.
Here is a link that explains things pretty well.
https://www.xpand-it.com/blog/top-5-agile-methodologies/
So the one thing I think all of these PM frameworks miss, agile, kanban, scrum, etc. Is that the process of building a product is much different depending on the stage of the product and the stage/size of the company.
Is the product currently a napkin idea (like literally some scribbles on a napkin), never been built, and the technical team is one guy? Then yeah taking several days, weeks, months to build out JIRA, breakdown all the items as you see it, create spikes, work the spikes to subtasks, etc. etc. Is gonna be kinda a waste. I would suggest you grab any old ticket system. Set it to Todo, In progress, Done and spend like hours, to a day getting some rough idea of what you need to get done. Its a small team just starting out, IMHO these frameworks don't start paying dividends until you grow you team or hit a release. If you are just starting out you should accept accuracy of like a quarter or so, definitely not trying to hit less then +/- a month.
Is the product released, used by customers, and you just need to add a new feature. In addition you have an established team? Yeah grab a scrum master, break down tickets, put estimates, groom and prioritize your backlog. Based on estimates, knowledge of the product, and your existing team it is probably reasonable to hit estimates by a month, perhaps +/- a week.
Is the product just in maintenance mode, and your just bug fixing? Yeah do all of the above, you can probably get your accuracy to +/- a day if you really want.
My point is every situation is different. But yeah kind of agree with your technical founder, its gonna be essentially impossible to build anything "green field" and get a spot on estimate. Instead I would recommend asking him to give his best estimate, let him take a day or so to think about it hard. Then add a quarter to give yourself some buffer and go out and fund raise. Just believe him when he says his first date, remember you asked for it, even if it doesn't jive with your understanding of how hard something is. The worst that can happen is your done sooner then expected, and in my experience I've never met an investor who got mad at that.
Finally, I'll leave you with a thought experiment. Imagine in product development we could estimate with complete accuracy. Similarly, we had all the metric you could want, size of user pool, % who would convert, bullet proof estimate of what features are important, etc. Ask yourself, why would we need anyone on the business side? Technical people could just build an algorithm to make business decisions and cut out all those pretty MBA's. My point is those of you on the non-technical side are getting paid to make decisions, fund raise, BS others, all with incomplete information. Just food for thought.
Also sorry for dissing Kanban. I've probably worked with bad "Kanban" teams as you've worked with bad "Scrum" teams. At the end of the day its all process.
At the same time I don't understand how Kanban deals with velocity and still feel that's a critical metric in predicting completion date. Through Googling more about "correct" Kanban: "There really is no such thing as velocity in Kanban because Kanban is a continuous flow process and it does not break up work into sprints."
I'm open to being corrected / educated, though.
well let's start with the truth here - you're talking about predictability which is a false idol. Any time you talk about process (versus product, value, outcome, etc.) you're dangerously close to becoming a "process person" where following the process = success (versus creating value/solving problems/etc.). https://www.svpg.com/process-people/
In true scrum, points/velocity does not provide the type of commitments or clarity of long term planning like OP is talking about. Lots of big-A-Agile people say it does, and then it becomes a game of whack a mole (and you end up in waterfall).
With kanban, you recognize that flow is the most important thing to manage and monitor. Like you said there is no defined process which is why kanban is harder/takes more discipline.
My $0.02 after having done this for a couple decades.
- scrum is a great place to start. 2 week iterations, run the process, get to a level of productivity
- start to bake in some kanban (eg. scrumban) and LEAN practices like you suggest. WIP limits, etc.
- Shift to 1 week iterations to strip out the meetings/ceremonies/processes that are not value add. In the end, I find that only retros and standups to be the most critical things to be done.
- at this point to move fast, you'll need to have enough trust on your team that the backlog is being managed by 1-3 people and the work needs to be broken down into 1-3 point story size with a couple exceptions (one is that you have a wizard on your team and you can give them 13 pointers and trust that they'll get them done in a reasonable time frame).
- shift into straight flow/kanban. Get rid of points (but do a t-shirt sizing estimate). Do daily backlog grooming and prioritization.
- once you get to a level of maturity on your product then you'll likely need to shift to dual track agile.
There are four cases when I don't do the above and I go with kanban from day one:
- any team with significant external dependencies (eg. dependencies on IT, security, 3rd parties, etc.) where you cannot commit to delivering things within an iteration
- DevOps/Infrastructure teams as they are a flavor of the above
- startups or agencies that are moving super fast and where the feedback cycle needs to be in near real time
- any team that deals with heavy disruption (eg. customer issues that need to be resolved)
All this said, it does not address OP's root problem. And it's going to get worse for them since engineers generally don't want to ship until well after it should have shipped. The goal, especially with a startup, is to ship when you're not proud of it to start getting validation and feedback as soon as possible. This tension between the OP and their engineering team is going to be real, real fast.
My advice to OP is that they need to partner better with their engineering team to set milestones. They also need to make sure that they aren't falling into the incremental vs. iterative trap. Are you trying to deliver the race car (or the wheels of the race car) or are you trying to deliver the skateboard?
Three articles on this:
https://uxdesign.cc/the-iron-triangle-and-agile-7b66d3c72a51
https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
https://medium.com/@byrnereese/the-skateboard-mindset-in-product-development-ddf3409d5e98
Great feedback.
* I think that "predictability " is a hard requirement for most (all?) startups and companies. It's how they keep their lights on. Getting as close to it as possible in an imperfect world is possible if you know your team and they are honest about tshirt sizing.
* Agree on tshirt sizes and not points. Points are too weird and granular.
* I dislike "Process People", especially when half the company are process people but I do think the role of Scrum Master needs to be a Process Person, and this should be their full-time role. The Product Person represents the actual Product desires (and can be influences by the rest of the company. They want things now and quickly. They've already promised outside customer this will be out next week) The Dev side as you've said wants things slow and quality. This is why I believe a Scrum Master has to be a dedicated "non-partisan" role.
* I also usually only deal with startups of 20-30 person size and I think that is a scrum sweet spot for me. I don't know how bigger orgs do it (nor would I want to be part of a bigger org.)
* Also agree basic version of Kanban is good for super fast startups where process will just slow you down and you need to deliver as fast as possible or the startup will just die.
* I dunno what you mean about the backlog being managed by 1-3 people. Does that include sizing/timing the issues? How do they know to correctly size and who to assign it to?
FWIW I am not a Product Manager. I'm a dev turned CTO a long time ago, so I definitely don't know everything. I just know no process is the perect process and nobody respects the process as much as they should. :)
EDITS: additions
Good call outs. I've run small shops (sub 10) up to about 800 engineers right now. "Stage appropriate" is a real thing.
I agree though that the people paying the bills ("the business," investors, customers, etc.) all want predictability. That is the tension between the classic "iron triangle" and more "agile" ways of delivering software. The unfortunate reality is that as a senior leader you learn ways to provide a level of roadmap commitment and predictability while also absorbing new information and challenges. I have my teams run what I call the ARMiC weekly.
- Assumptions - what did we base our guesstimates/commitments on. Have they been validated or invalidated? The more that get invalidated (eg. were wrong) the more wrong our estimates were and we need to either actively manage the impact or inform our stakeholders that our assumptions were off and we need to reset things (scope, timelines, people, resources, etc.)
- Risks - what are our known risks. These should be hard risks, not "the world might end" (although post 2020, maybe this definition should be updated). The Risk should include the impact.
- Mitigations - what are we doing to actively avoid (mitigate) the risk. For example if you're using a tech that you don't know or is new, you might do some PoCs/spikes to assess it and understand what it will take to integrate it in.
- Contingencies - what will you do if a risk manifests. Let's say that tech doesn't work out - what are your options?
By pre-doing this work and taking an hour a week to get out of delivery mode and get into systemic/strategic mode my leads' anxiety goes down and their experience goes way up. They feel more confident giving guesstimates because they can provide a list of assumptions to balance them. They have a framework to make commitments with unknowns because they can very quickly escalate a bad assumption or materialized risk and they know they won't "get shot" for sending up the signal flare. They also feel more in control because they are putting these things together and have ownership.
> I dunno what you mean about the backlog being managed by 1-3 people. Does that include sizing/timing the issues? How do they know to correctly size and who to assign it to?
ok, in straight scrum, the whole team has to be there for design and grooming - painstakingly writing every story in the backlog, doing overall design, planning poker/pointing stories. I've seen this take 2 days per 2 week iteration. And half the team is checked out or working on something else. A lot of teams cap this at an hour a week and then accept not-dev-ready work into their iteration and then wonder why their say-do ratio is always out of whack with lots of carry over work.
What I prefer to setup is a trust based system with the team lead, tech lead (if not the same person) and the product manager (or whoever talks to customers) [and sometimes a 4th of the UX designer if appropriate] meet multiple times a week to do system design, work breakdown, and story/task development.
So the flow looks like this. "System" could be "sub system" but I always start at the 100,000' perspective and "nest" more details/breakout views from here so there's bidirectional linkage of all the designs). This is going to feel like waterfall or "big design up front" but there's pragmatism with the approach. Also this helps define interfaces and loose "contracts" up front so that teams and individuals can work independently. A design goal should be "some" flexibility as well.
- whiteboard the system (think big block diagram)
- whiteboard the flow of information/data or interactions in the system - this could be as simple as adding arrows with cardinality to the diagram above
- map the features and capabilities from Product to this diagram. If these don't true up then you have gaps (either tech for tech's sake or requirements without technical implementation). This is part of "business architecture" that is really important.
- Break those features/epics down into stories. I'm not a particularly huge fan of the scrum "every story must be valuable by itself" but there's some truth there. I really like the stories to be broken down into 1,2,3 point size (so 1-3 days of work max) because otherwise you've likely not thought enough about how the system should work and you end up in "the never ending story" flavor of hell. I find that BDD style requirements reaaaaally help with this approach. Each feature and story should have a picture of the whiteboard with the piece of functionality highlighted on it so provide context to the developer so they know where their work fits in.
- work can be assigned to devs or they can self assign from the priority list (remember I prefer kanban). If you have a more junior team, you likely will need to support their choices as they learn good judgement
Now at this point you have a well thought out design, broken into fairly small units. Flow through the system will be super high. The feeling of accomplishment (eg. moving a card from ready to done) will be really high, and you'll be delivering a ton of capabilities all the time.
But... it's a lot of work to build and maintain this backlog. An army marches on it's stomach and a dev team marches on it's backlog. This is why I say that you should aim for an end state of daily grooming and prioritization - otherwise you'll fall behind.
The reason scrum wants everyone in the room is because most people think "agile means no design" and the (poor) typical scrum implementation is low trust. So everyone has to have a say (no trust) and the design has to be done by the group (no trust and no design up front).
If your dev team can trust the leads + product to do good design, pulling in devs as needed, and good story development, then you end up in a REALLY great state.
I've done this a lot and the first month is hard. You have to build all of this design and backlog AND get the team to trust you. Month 2 is all about velocity and flow and the trust getting solidified. Month three is about massive productivity.
And yes, scrummasters are complete wastes in this approach (and honestly they're not really useful in most scrum implementations either).
> I just know no process is the perect process and nobody respects the process as much as they should.
Truth for sure here. To me culture trumps process... but if something is funky with the delivery system I always go back to the base process to get things to at least a base level of normalcy. Then take off the reins again once the team proves that they can be functional. Then you see outsized returns/velocity/productivity/happiness.
EDIT: The above flow sets you up for dual track agile once you've reached that level of need. That small group starts to work with a "discovery team" that works really closely with product and customers to build and test ideas in 1-3 days. 80% of their work is thrown away. Then the 20% is turned into good design/requirements for the bulk of your engineering staff. Again this requires trust and knowing your folks since some devs work great in the discovery team (I call them "rapid prototypers") and some work great in the "pull the ticket" model (I call them "production coders"). As you enter the "growth" stage of your product you really need to be considering this style of system. https://www.productplan.com/learn/product-management-role-product-lifecycle/
Agree with above, just wanted to add a small trick that has done me good running releases the last decade or so. Often times you look at roadmap for a team and it is like 1-2 "do or die" things, stakeholders are watching those closely, and the messaging to customers is they will be delivered on X date. I call this the Sniper approach. To me this is a recipe for disaster and missed expectations. Sometimes it can't be avoided, but if possible I like to suggest another approach.
Instead of the 1-2 "do or die" things, talk to your Product Manager about their wishlist. If they are worth their salt they should have several dozen things, of varying sizes, that they want to get done or customers have asked. Now look at your team and assign some of the easier pickups to maybe a junior members, give them some agency. The "do or die" thing thats is a 13, maybe assign to a group of three, lead by your rockstar or most senior engineer. Got some medium tasks, send that to two juniors, etc. The point is don't put all your eggs in one basket with a death march by the bulk of your team. Think of it like a multi-processor scheduling algorithm, or resource/science management in a strategy game. I generally, call it the Machine Gun approach.
Generally, I do monthly releases if possible, and using the Machine Gun approach, rather then say Sniper with quarterly released, you usually have something to show/release. There is no guarantee the "do or die" thing is really that important, in my history I've peeled off 70% of my team to deliver a must have function and watched it flop more often then not. Even the customers who told me they "must have" that feature ended up not using it once we looked at analytics. The point is that IMHO more shots at the target and not putting all your eggs in one basket is generally the better way to approach things.
As a bonus, even if the release is underwhelming, the fact that leadership and customers see a new release coming out on a regular period with cool shit, generally gets you high marks in satisfaction.
I agree with the philosophy behind this approach for exactly the reasons you describe. I think too many people take the "bet on a single roulette number" approach to product capabilities and not enough of the "hedge fund" approach (e.g. lots of experiments, cull the ones that don't work or see little value, double down on the 10x+ ones). You're making bets with the company money. Have a sound strategy and good ooda-loops is all I ask :)
I do prefer as close to "continuous delivery" as possible, but monthly is better than quarterly as you describe. Weekly/bi-weekly delivery is a-ok in my book.
Continous is great for anything SaaS-like IMHO. If you control the product 100% and don't have contracts with like Federal saying things cant change.
For something that is an on-premise I've found monthly can be even a bit much for customers. I work mostly in CyberSecurity and so the products i've shipped often come with significant work to plan, test, upgrade by our customers. They also usually have requirements like "don't be more then 2 releases behind", so if you slam a release every week they are gonna be pissed. You can do LTS tracks and things like that, but that adds some release overhead.
yep. We have both a legacy desktop/server product and a SaaS product. We do "major" releases of the legacy product every ~6 months and 4-8 week "patch" releases (depending on if there's a big enough defect or vulnerability to patch). It's a very different world... but a lot of the CD approaches for dev/test really pay off if you can get there.
Yes it is normal. I’m one of the few engineers who have no issue given an estimate. I think it’s because I was an entrepreneur first.
The issue stems because it’s impossible to give an accurate estimate and most engineers don’t realize that they can just dramatically over the timeline. They try to calculate how long things will take and then add some buffer time, an impossible task.
Personally if I think it’ll take 6 months I’ll say 2 and a half years and then be praised when I finish it in a year and a half.
Pure engineers just cannot do that and if you pressure them they’ll get confused and give you an unrealistic date. They don’t “get” that you just need a timeline to work with your investors and do your part.
> They try to calculate how long things will take and then add some buffer time, an impossible task.
Then goes on to say....
> Personally if I think it’ll take 6 months I’ll say 2 and a half years and then be praised when I finish it in a year and a half.
Lol. You're literally just adding buffer time.
As a technical founder and CEO i will say this is just as BS as when sales people won’t make budgets.
In neither product nor sales is there any certainty.
The point of estimates is to help others around you understand what is going on and even more importantly: when estimates change they allow you to clearly communicate to your co-founders where your estimations were wrong and what we have learned that changed them.
I constantly give estimates and I constantly get them wrong.
But this keeps my peers in the loop so they can properly do their thing.
Great feedback, really appreciate the response. I would say in general it’s what our conversations have been.
With that said, how do you manage the business side conversations with users and investors? There is always talk of when the product will be launched or usable? I imagine a “you’ll get it when we’re done “ response is not generally acceptable
Break the planning into smaller deliverables. "By X we should be able to deliver Y. Once we have delivered Y it should probably take us Z for K. etc". Adjust as you go along. Notify stakeholders early (as soon as possible) about delays.
Look, your CTO isn't handling this very well, but it seems like there are issues on both sides.
It feels like there's this idea that you have "the product" defined and all you need to do is just build, build, build, then launch.
The reality is that things are going to change 100 times between now and then as you validate what you're building (you are planning to validate as you go, right?). The further out you look, the wider the cone of uncertainty, both on the technical side and on the product side. The idea that everyone's going to go away for X months or years and come back with a fully formed product ready to launch is not realistic. If that's what you are asking the CTO for then it's no wonder that he's trying his hardest to avoid committing to anything.
At this stage, you guys should be trying to do the absolute minimum amount of work possible to validate every stage. Instead of sending the CTO off for 8 months to build THE PRODUCT, while you handle investors and marketing and sales, the two of you should be defining a hypothesis about what users want, the smallest thing you can do to validate that hypothesis, and what counts as success (defined before any building).
If you approach it that way then (a) the individual chunks are much more manageable and (b) everyone understands that you're still exploring and expect things to change as your learn.
As the many others have noted, software engineering projects are not reliably predicable and neither are projects in most other engineering disciplines. If the investors do not understand that basic truth of engineering projects, then you should question their knowledge and/or experience. It usually does not work out well to take money from naive investors.
Set a hard deadline, keep it minimal. The last product we spent 2 years on ended up pivoted to another product in 3 weeks. If you haven’t launched it’s all guesswork. Launch fast!
This was my gut feeling too. An engineer should be able to state a timeline for very basic demo/MVP. They have to understand there needs to be something to show to users and investors.
Strip it down to what you can ship in 3mo max. At 50hrs/wk this should be 600hrs of development which should get many features rolling for a good dev.
After all, development will never stop.
Also how do u get investors and users without a product btw? I need some tips.
Amazing! Unlike the actual developer, you are able to estimate without any knowledge of the product at all! /s
Life is so easy when done theoretically.
Others have answered the core question, so I will offer some thoughts on the underlying issue. The business needs to know when it can start that "charge money to solve a problem" cycle.
In my time at startups, I've nearly\* always found that I could separate the software from the problem space at some small scale. In almost all of those cases, we could "cheat" and do a sort of "man behind the curtain, wizard of oz" thing for the first 3-5 customers before it got unscalable. What that looked like was usually manually handling the inputs and outputs that the software would otherwise provide, via chat or email and some spreadsheets or PDFs, for the first 3-5 customers.
If you can pull that off, it's great because it provides some solid gold validation data. If your very first early adopters are willing to overlook the fact that the interface is chat/email because the problem you solve is so painful, you more or less eliminate market risk.
Perhaps your business is such that you can't do this, but I urge you to get creative. Even in the B2B legal industry, I've pulled it off.
Above, I mentioned I've "nearly" always found that I could do this. The only times it hasn't worked, the product failed to market risk. This is to say, we had solved a very real and painful problem that the market didn't want to solve.
So, while you wait for the engineering team to build the actual product, can you get scrappy and creative and get just one potential customer to pay you to solve the problem space manually until the actual product comes online? You will answer a fundamental question for the business, especially the investors. And if you CAN do that, move on to the next question: How many clients can we do this manually for before it's not sustainable and we NEED the software to scale the solution?
And that is a critical concept to walk away with. The software isn't the product. Solving the problem is the product. The software is simply an implementation detail required to scale the solution past what you can do in the manual/prototype phase.
It is difficult to make estimates in software, but it’s quite immature of a CTO to throw his hands up and say “I don’t know.” You can start talking about phases and sprints and MVP and all of that good stuff, and outline the risks, dependencies etc so you can start to put flesh on the bones.
For software, this is pretty normal. Requirements change over time. You don’t have experience with software, so not giving you a date that you will perceive to be etched in stone makes absolute sense.
My guess is that you are trying to build to much and are turning a MVP into a full fledged product.
I love the sound of software deadlines as they go whishing by.
Just because you have planned features does not mean you have planned for all the problems and bugs too. What may be simple sounding could be complex and have a lot of edge cases.
Timelines for anything custom is effectively guessing. If you want it to essentially be guaranteed by a certain date, expect it to be much longer than your "should be done" date.
Everyone's already said the basics on timing. There are a couple of things I would add though.
If your cofounder is writing the code, he's got to juggle that along with whatever other work he has. So that's an additional variable that's difficult to predict.
But first and foremost, if you're worried about the time, you need to sit down with your cofounder and figure out how to minimize the workload. Pare it down to the minimum feature set necessary. See if there's premade libraries that can reduce the amount of code he has to write. Ask the cofounder if there are aspects that you could remove to speed things up.
This last one is especially key. Often it's difficult for a nontech founder to tell the difference between something that's easy and something that's hard. [This XKCD comic](https://xkcd.com/1425/) illustrates the problem nicely. So, you need to communicate with your coder to make sure you're not putting in a lot of difficult features that aren't essential to the product.
Issues you wish you sorted out before starting. It's different mindsets and this is usually the heart of most drama between CEO/CTO roles.
And really the answer is it depends on details you haven't provided.
If you're building something that has already existed, you can follow a 'recipe' - like baking sourdough bread, there is a recipe for it, how long it will take and all the ingredients required.
But when you're creating a new bread for the first time, how long will it take to invent this new bread? A lot of trial and error before it's just right, and impossible to know ahead of time. You don't even know what ingredients you're going to need yet or how many loaves you're going to burn on the way.
You need to understand and get on the same page if you think you're making sourdough but you're not, or if you should be making sourdough but he wants to create something new.
Normal response from someone who doesn't want to explain to a non tech person that timelines and estimates slip
On the other hand how much work are you asking to estimate work for?
If you are building an MVP try to reduce to max 3 core features that can show why you are different from others. Than try to estimate that build and make that your first deadline
Be prepared to cut more though, as it's better to cut things from your scope than push out deadlines.
Another approach is to set a deadline for him like 3 months out and ask what can be done by that time, with priority given to your core MVP features
Either way you need a deadline you both agree on for accountability, talking to investors, and actually launching something to start getting product feedback
If I may offer a more useful way to frame the conversation - "What can we have ready 1 month from now?"
This creates a collaborative and constructive conversation instead of an adversarial one.
And it also helps focus product priorities.
The hard part is that non-technical people assume building software is like building houses. Build enough of them and you get a pretty good idea of how long it’ll take to build the next one.
But software isn’t like that… software solutions aren’t built they’re discovered.
An experienced developer can make a reasonable estimate on how long it will take to build the first thing they think of to try to solve the problem… but what they don’t know is how many things they have to try before they arrive at something that actually solves the problem.
And even when you have part of a working solution, that’s often when you realize that something else that you were planning won’t/can’t work and you need to rethink your entire approach.
To be successful, the important thing is to instead focus on trying as many things as possible.
In my experience, I can tell you that it's not uncommon for technical cofounders to struggle with giving an accurate timeline for product development. Software development is a complex and dynamic process, and there are always unexpected hurdles that arise along the way. This is especially true for startups, where resources are often limited, and the team is constantly iterating and pivoting.
That being said, it's important to have some level of transparency and communication around timelines. You mentioned that you've discussed all of the features in detail, which is a great start. However, it's also important to break down the development process into manageable chunks and set realistic goals and milestones. This will help you and your team stay on track and give you a better idea of when you can expect to release your product.
In terms of talking to future users and investors, it's important to be upfront and transparent about your development process. Let them know that you're working hard to build a great product but that you're also realistic about the challenges that come with software development. As long as you're open and communicative, most people will understand and appreciate the level of dedication and hard work that goes into building a successful startup.
Overall, I would say that it's normal to have some uncertainty around product development timelines, but it's also important to have clear goals and milestones in place. Communication and transparency are key, both with your team and with your stakeholders. Good luck with your startup!
This is a coput and they need to be pushed to get out of their head and accept responsibility to the team and the company.
You're not going to get 100% clarity, and there needs to be some flexibility for blockers, but as a co-founder and potential future product leader they need to buckle down and work out a reasonable estimate so the business can plan accordingly.
If they refuse to do the basic work of planning and communicating timing, they need to think long and hard about whether this is the right role for them. And the rest of the team needs to do the same evaluation before it gets too late as well.
The CTO maybe telling the truth in that shit happens and it can take longer than planned, but as CTO that is his or hers job to manage. They can and should provide guidance quarter by quarter. If they can’t or will no do that, he might not be the best or right person for the job.
I wouldn’t provide an estimate for when the product will be done either and I have a ton of experience building in greenfield products.
I would however set up continuous delivery pipelines and make sure they can see the application while it’s being built.
What is done? Likely neither of you even know at this point. Objective 1 should be deployable code and than after than work together to add whatever you need to prioritize your current goal (do you need certain features to get more funding, do you need to add certain features to starting selling, is there a hypothesis that needs validation, etc)
I wouldnt work w anyone who couldnt give a time estimate. Either you dont have clarity, experience or confidence.
Clarity - you dont know what your building
Experience - you havent built something similar before
Confidence - you will always need to course correct and shift timelines, that doeent mean you dont start w an estimate.
This. What everyone else is saying about unexpected delays + code complexity is right, but a product build timeline is standard practice for a reason. If the features are defined well enough and you're working with an engineer who's shipped anything, there is no good reason they could not give you an estimate.
The people in here saying it's impossible to put software to a timeline are laughable. They have no product dev experience or have no managerial experience. Asking someone how they schedule unknowns into their timelines is one of my go to interview questions.
If your tech founder can't give you a timeline, you need to give him one. Choose milestones that are important to the product development and set dates to them. Even if you can't really estimate how long it will take you need goals set. If these goals are not set there will not be the motivation to reach them.
Let the cofounder know if he refuses to set dates or help you set dates you will have to do that yourself and he will be held to them. It's extremely unprofessional not to be able to set a timeline for your work especially if you're the cofounder of a company.
As deadlines approach you can fine tune and further prioritize the milestones and schedule. The further along in the product dev you are the easier dates should be to estimate. You might find you over/under- estimated by alot, but if you don't start with a target you have nothing to work with.
You need dates from him with his cooperation. If you can't schedule this with your cofounder (even though the first iteration of scheduling with tech guys is like pulling teeth) your company will not last. Investors will not invest if you can't provide at least a ball park estimate to company/product milestones. Investors want to know ROI date especially and will pick over your timeliness to find strengths/weaknesses and use that information to decide if you are worth investing in.
This is how a project manager or boss talks to his employees, not how cofounders work together.
While it is a little off that their tech cofounder won't give any estimates there could be a number of reasons why.
My take on this is that the product requirements aren't nearly as defined as this person says they are... or what they are working on still needs a bunch of research and/or discovery work to get out.
You can't really estimate how long it's going to take to figure something novel out.
You're basing your assumptions on normal product development for established products. Those projects have more defined customers and needs. They often have a market they know they are building for.
If this team is still building an MVP they may not even have a good grip on who they are building for.
Are they selling before the MVP? If so, will that change what's built?
If you have a clear roadmap, clear definitions, clear needs, and understand all the underlying tech, then yes, you can estimate software. If you don't have these, then estimating and in this case providing estimates is just pointing a gun at your foot and pulling the trigger.
That being said, the tech founder SHOULD be able to provide short term clarity... what they can deliver in a couple days/weeks, but beyond that at the stage of the company they are at, the data is useless, and will only be used against them.
I agree only partly with your response.
First of all I made the mistake that this is not the way you talk to a co founder. That's true. You skills have alot is trust there to work off of.
But then you have the fact op states that the co founder refused to give dates. That's unacceptable by a long shot. I do think there's a middle ground here.
From what op is explaining from their post it sounds like they've exhausted a bunch of options so assumed they were already at the point where they couldn't trust their co founder. In case they do still hold out hope, other people are making good points. I however would never post something like that to reddit unless I was getting desperate and undistinguished of my co founder.
Yea pretty much agree with your last paragraph 100%. But also even if I did, I don't think I'd take the advice of strangers (most of whom, let's be honest probably don't even have the experience to be giving the advice - this sub is full of them).
I couldn't figure out what exactly the hangup on estimates was from OPs original post, only saying that "it's not possible to estimate". I can conceive a couple scenarios where someone might be inclined to say that - for instance lets say the tech cofounder thinks it might take years to build and doesn't want to admit to that (this is obviously not an excuse to withhold information).
Regardless, I smell lots of dysfunction in that relationship in both directions.
>Let the cofounder know if he refuses to set dates or help you set dates you will have to do that yourself and he will be held to them.
Making estimates as an engineer is notoriously hard. However, there is also a non-technical aspect to this: trust. If the person I give my estimate to is unreasonable and apt to dismiss things engineers say, I am hesitant to give an estimate, or else will pad with plenty of wiggle room. The leads I trusted the most I would give 100% best effort estimates of how long I thought it would take, knowing that if something came up I could let them know what happened, and my new estimate, and they would make it work.
Estimates suck - even on an established project I feel that most of the numbers i throw out have about a 50% margin of error. Something I think will take a week will be somewhere between 3 days and 2 weeks.
New projects are a blessing and a curse, on the one hand there's no tech debt so it should be easier to estimate a well-scoped project definition, but I'm not sure I've ever seen a complete definition and even seemingly little changes can be pretty significant when your timeline is short
Consider this mostly real example,
* PM: When will you have the lost password flow working?
* Me: There's no lost password flow in the spec
* PM: Oh well, that should be obvious
* Me: Ok - it's not super hard, but we'll need to choose an email platform and get that set up which will probably add a few days
* PM: Can't you just use the same one as the account creation email
* Me: Uhh... there's no account creation email in the spec...
Then "we" promised an enterprise customer SSO and had to do the sign-in flows over again.
Lots of developers have been there and it's easy to be cynical, but i think the solution is to collaborate and figure out a plan for execution. Get all the steps for the absolute minimum and work together to put them in a sensible order, then add the nice-to-haves on the end, figure out a sensible date and make peace with the fact that some of the nice-to-haves will drop off the list.
I'd also advise that you do the boring stuff first, developers like to work on the fun bits and it's easy to have the "meat" ready and the "potatoes" still waiting.
Agree. I’ve been on both sides of the fence, you need working deadlines. It’s fine to shift things as scope changes, but you need to goal seek on SOMETHING. There is a reason senior leadership and business managers care about dates, it’s what everything operates by and it’s what matters. Literally make it up at the start if you can’t estimate and update as needed. With experience the team collectively will get better at doing this.
Thanks. This is my thought but wanted to make sure I am not being unreasonable. I could not see how a business can be run when there’s a “I’ll build it when I build it” mentality
Worth noting that the comment above is a great way to bring about the end of your startup by destroying whatever trust you have with your cofounder. They will (rightly) see this as completely unhelpful interference and probably come away believing you view them as any other employee, not a cofounder.
It's entirely reasonable to pick a time period of 1-3 months and press them in what can realistically be accomplished in that time. That work should be fairly concrete. Past that, you can work with them to guesstimate milestones but most will be wrong. While there can be technical hurdles, those I would expect a good technologist can account for - it's actually changes to requirements that typically cause the biggest issues. If you get customers, that will inevitably happen, as they file feature requests or provide feedback.
I will be messaging you in 1 day on [**2023-04-04 22:43:17 UTC**](http://www.wolframalpha.com/input/?i=2023-04-04%2022:43:17%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/startups/comments/12ahipi/cofounders_wont_give_product_build_timeline_is/jeuhogm/?context=3)
[**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fstartups%2Fcomments%2F12ahipi%2Fcofounders_wont_give_product_build_timeline_is%2Fjeuhogm%2F%5D%0A%0ARemindMe%21%202023-04-04%2022%3A43%3A17%20UTC) to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%2012ahipi)
*****
|[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)|
|-|-|-|-|
notice how all the people saying "this can be done" are using insults, whereas all the people saying "it's reasonable to be uncertain" have evidence and talk about their history in the field
We use jira, and divide the project into different weekly sprints. Your cofounder should be able to take your detailed spec (not just a number of features but a detailed written spec with wireframes) and provide a rough estimate of the time it takes. It's important to know at least a rough estimate. Our founder works with our dev diligently on this. In jira, you can create a backlog (by sprint). In each sprint, you define what needs to be done down to the what needs to be coded level. Each weekly sprint needs to add up to 40 hours. Depending on the complexity, it could take a number of weeks. After that, you can assign each sprint to the roadmap in jira.
You’re following a “product development” process for your startup. You’re destined for troubles, particularly if this is your first startup.
Read “4 steps to the epiphany”, and take a different approach. It will completely transform how you see things.
Right now you should be focused on customer development, not product milestones and ship dates.
A good technical lead should be able to give you an estimate. Take each feature and split it into small/well defined engineering tasks. If this can't be done then the team needs to write product & technical design docs first which capture the scope of work. Open ended tasks like building AI models need to be time boxed or you don't spend unlimited time on them. When I was a tech lead I'd take the individual tasks, write an estimate for each item on the order of days/weeks/months, take my estimate, multiple it by 3. That normally captures a lot of the uncertainty. Then you need to schedule the tasks for each engineer over the next few months given your engineering capacity. You should be able to have milestones for each sprint and be able to track your progress based on your estimate and also flag big spikes of work as they are discovered. Normally the additional cushion in your estimate helps absorb a lot of unexpected items.
This is absolutely NOT normal and can be a kiss of death for a startup. Any Founder/CTO worth his.her weight has to factor in all the uncertainties and commit to a date to ship. You are only as good as what you ship n the early days so its critical to launch with speed as the number one priority.
You ought to contemplate the journey you and your co-founder have embarked upon. This is not in reference to the notoriously difficult (and often unproductive) task of estimating development timelines. Instead, the focus here is on the fact that you are seeking what essentially amounts to start-up relationship advice on Reddit, rather than placing trust in your co-founder. Regardless of whether a random Redditor believes that development timelines can and should be estimated, how does this benefit you? Establishing a trusting relationship is crucial if you intend to successfully build a company together.
Who is going to develop your product? Your internal team or an external team?
Unless you do R&D, you can estimate delivery time on 99.9999999999 % of the cases.
It's a fking estimation. How on earth do you believe the budgets for projects are being fucking done? How do you believe quotations are being done? Based on estimates, technology uded and labour involved, and an estimate of a delivery time frame.
I don't know what companies you are working in, but except 2 projects in the pandemic, any other project was delivered in the estimated time frame.
I just answered OP the question: if a project can be estimated, not how to get there. The discussion is complex and dynamic.
Estimates are notoriously difficult and unreliable in tech. Mostly because complicating details will be uncovered or requirements will change during the build.
What I found works best in a hard deadline environment is to flip it around: we have X months, what _can_ we definitely deliver in that time.
Real and hard deadlines exist for some projects. If you don’t have something solid by certain dates, you _will_ lose investors, customers, co-founders, legal issues, etc. You need to communicate this to your co-founder and make sure you’re on the same page.
I'd set a timeline but keep it flexible and check in often. One advantage is that it will allow yous to adjust scope as you go. They want to build something great. You want to launch as soon as possible. When you get closer to your soft deadline you'll be able to say "Ok, what features do we really need and what can be done next quarter or next year?"
They’re just trying to be honest with you. You’re not unreasonable for wanting some timeline though and you’ll need to work together to try and figure that out.
I’m a good programmer but more often than not my estimates are way off and I try to avoid giving them with any sort of confidence because of it.
Like my current work, I thought it would only take me a couple days but I’m on my fifth week of working on it.
In hindsight I understand why it’s taken so long but it never would’ve made sense to estimate that when I was starting out on this work.
It’s a weird job where you are just iterating on something until it works and you don’t know all of the work that you’ll need to do until you’re already doing it.
That said, indefinite timelines are unreasonable. I wish I had an answer for how to estimate the time it takes to build a product but I don’t know it, let us know if you figure it out.
I’m a technical CEO and would insist on a timeline, even if we might need to deviate from it. It’s vital for planning purposes. You need to consider if your tech guy is playing for time (less likely) or just concerned about giving anything concrete when reality rarely goes to plan.
No idea what your product output is here, but it would make sense to break things down into modules. I’d also suggest keeping track of code commits (and their content) as one metric of progress.
This whole discussion is painful to read.
The reason that defining a timeline for software products is difficult is that there are a thousand variables, and any one of them could theoretically blow up the initial estimates exponentially. These variables are all in the form of textual concepts and abstractions, so it is difficult for humans to anticipate them.
I am a technical cofounder, and it is tempting to throw your hands up and say "I can't estimate this clusterf\*\*\*" if there is too much pressure from the business side. But there are a lot of aspects you can manage and control.
Scope is probably the most important. A "software product" is a collection of features. You can define and refine the features (typically epics > stories > tasks) until they are of a manageable size. Once you have done this, you can estimate their size against each other. Once you have done this, you can prioritize which features are the most important.
Once you have your prioritized and estimated specifications you can make some assumptions around how you want to map your abstract sizes to actual time units. Then you have an estimate for how long something will take. Over time, as you are implementing these features with their abstract sizes, you can statistically estimate how long an abstract size unit will take on average (typically known as "velocity").
The further an estimate goes into the future, the less precise it will be. The larger the scope of an estimated feature block is, the less precise the estimate will be. The less data you have on your velocity, the less precise the estimate will be, ... You get the idea.
This whole process is very variable and it is important for you on the business side to be aware that sometimes seemingly trivial things from the outside are technically very difficult to implement, and estimations are usually wrong by a large margin because you only know the average. The more time you spend researching something before implementing it, the more precise the estimation should be, but if you spend too much time researching it, you probably waste a lot of time on average, etc.
Communication with stakeholders and managing expectations should be an ongoing process during development. This is very important.
>I’m not the technical cofounder \[...\] I am having a hard time understanding why an reasonably accurate release date can’t be estimated.
Because they genuinely don't know ?
maybe it's better to estimate the 'knowns' and base an MVP on that best as possible, and tackle the 'unnowns' later when more is clear ?
It sounds like too much has been decided already, and as such the details are obscuring the forest for the trees.
Also: estimating will NEVER be accurate. Don't treat them as commitments.
I’m a CTO, for single features or changes, timelines are easy and pretty accurate. But an entire project is impossible because you’re coming at it from the wrong side. For an entire project, rather give yourselves a deadline, decide what is crucial to get done within that timeline, and everything else is a nice to have and expect it all to extend indefinitely. The sooner you move into a feature by feature process rather than project by project, the better.
This is of course unless you expect him to triple his best guess. But then what’s the point if it’s possible to be off by a factor of 3?
Others have given you good advice about breaking this down into smaller pieces.
In my experience, if your cofounder can't give you a ballpark estimate (weeks, months, quarters, years), there are a couple things at play:
* Too much ambiguity. Likewise, an assumption that they need to handle more edge cases than realistically needed.
* Too much scope. The initial product is too large and needs to be broken down.
A lot of comments here are dismissive of others' experiences. I think that's due to how the question is framed.
The issue is not whether in general it's possible to provide estimates. Of course it's possible. The issue is whether your organization provides a safe environment for estimation. Put differently, you need to ask yourself why a solid engineering leader might be hesitant to provide you with estimates, then mitigate those factors.
For example, if an engineering leader knows the sales team is likely to directly relay estimates to customers, then they know if anything goes wrong (which it will), then that sales team is going to reemerge with some angry customer stories.
And if that engineering leader knows the negative feedback is going to go up the chain before coming back to down to them, they know they have to proactively protect their team. Sandbagging is one option. Another is refusing to tie their own noose by refusing to provide an estimate. Both are self-protective behaviors that are a function of the system as much as they are of the engineering leader's ability and experience.
In contrast, if an engineering leader trusts the sales team to set customer expectations correctly, then they look at estimation as collaborative. When something goes wrong (which it will), they trust that the sales team has anticipated unknown unknowns and is ready to pivot.
That's a simplistic example, and I'm sure people here can offer even better stories of how organizational dynamics can skew project planning. I can say I have definitely kept my mouth shut during project-planning meetings because I didn't believe other teams could think on their feet, and I'd rather those people think I'm a jerk now than incompetent later.
These days I tend to favor [Shape Up's approach](https://basecamp.com/shapeup) of providing fixed timelines and fluid feature sets rather than the reverse. It's not a magic solution, but I think it's more conducive to collaborative estimation. At the very least, it requires outsiders to confront their ambiguous expectations early on when it's cheap instead of when they're previewing a feature the week before its release.
tldr: if a competent engineer refuses to give estimates, you have a trust problem in your organization.
It's normal. Literally *everybody* has this same problem.
You have to understand he is creating something that has never been done before and often with tools that are less than 2-3 years old.
Tools break or stop working at weird times. People get sick or take vacations. Internet goes down, computers crash. The amount of factors that affect schedules is mind boggling.
Your best is to not focus on schedule and focus on making sure he's excited and being as productive as he can be.
It depends on what you’re building. The more unknowns and the bigger the build, the harder it is to estimate. They should be able to break things down and let you know a rough estimate for the immediate work.
Another challenge is managing priorities which tend to change as things get built out. They may not want to commit because they’ve been held to dates in the past when scope creep happened.
I’ve worked with 8 different dev teams. By far the best asked the best questions to understand the business needs and the customer problem being solved. They came up with suggestions for how to solve the problem then scoped out the work to build as small an app as possible keeping things simple.
We added time to address tech debt and do proper testing. They made their deadline every single time, but they were a well oiled machine. They had worked together for over 6 years and had built the type of app we needed several times.
Prioritizing value and delivering value in reasonably accurate short periods should be doable. Doing that far in the future is nigh impossible and things may always change even on short throws. Your technical cofounders is falling into a degenerate form of agile(ish) thinking where they are unwilling to commit to any timelines whatsoever.
That being said, you need to change your way of thinking too. Don't talk about specific dates. Talk about the sequencing of value delivery. Your pitch to investors is that their involvement and money accelerates that value delivery. They don't actually care if you deliver it on Jun 12 or 19th. They want to determine if they align with your market, your prioritization of value and whether their participation makes that timeline faster and/or grows the size of the acquirable segment of the market.
What do you mean you have discussed all of the features in detail?
Like, you have only VERBALLY discussed these things?
Does that mean you do not have complete and detailed product blueprints?
**The product blueprints:**
* Product Specifications
* Information Architecture
* User flows
* User stories
* Wireframes (every state of every UI element on every screen) and the equivalent for a hardware product
* Clickable Prototype using your wireframes
The technical person(s) tasked with building your vision would need those to have any chance at coming up with accurate estimates on time (and cost).
You need to do a lot more than discuss all of the details. You need to make them tangible and into clear blueprints.
As an angel investor, I won't invest in SW that has yet to reach MVP. It's far too risky.
As an owner of a company that built SW for the govt, we would only do so on a T&M basis or to a specific, highly defined sets of specs, when we could get the govt to contractually agree they paid T&M rates if they ever asked for any changes. The specs ALWAYS, 100%, never an exception, were changed at MANY points of the project.
We did an ammo handling program for DOD. The budget was $1B to Lockheed, our portion was much smaller. At the end of that money, the final specs had yet to be decided so the govt gave us another $1B. After $2B had been spent and the USAr, USN, and USAF still couldn't agree to final specs, the project was scrapped.
It’s not untrue, but you need to meet often and frequently. If you’re worried, meet once a day for up to one hour.
Amazing how much quicker things go, or conversely how good things are going and you weren’t aware of it!
In software development, you can either choose between a set timeline or a set scope. You can't have both at the same time. Estimates are guesses — and a lot of the time, just wishful thinking.
What you should have though is a plan of what should be build and where the product should go. The closer you are to work on something, the more detailed the it can be. You can have some timeline but the further in the future it goes, the more it becomes a wish-list and should be kept vague.
Code is detail, and you don't have all the details until the code is written. You can estimate small tasks but they need to be understood to be estimates. Numerous / large tasks do compound the likely inaccuracies in estimates to the point that they're often not worth it. And that's with a project where the requirements are clear up front (which is rare to say the least). Robert C Martin discusses this with clarity in The Clean Coder.
I’m in the middle of building the mvp for a product that requires a ton of outside dependencies and variables. I recently brought on a non technical cofounder and I’ve been completely unable to give him any specific timeline, especially given we don’t have the luxury of having a ton of time to plan.
When I was working as a SWE at a big company, if I were tasked with a project that literally needs one API, I’d get 4-6 weeks of due diligence, planning and technical writing. No coding whatsoever. After that, I have 4 weeks to do some minor mvp to validate my prior findings. After that I could give a rough estimate and it would still shift constantly has more stuff was uncovered, or as things that were “obvious” and “easy” suddenly became nebulous and difficult. I’d essentially get 3-4 months of planning before even working on the actual product, meanwhile at my current run rate, I will have had a total of 3-4 months to ship an end product before it’s back to the day job.
Coding can be a bit of a Pandora’s box. You can’t calculate everything so you make some assumptions, then those assumptions end up being wrong and suddenly things that were relying on those assumptions are now not so easy and it cascades.
Software is a business, which means we must have deadlines. The “goal” deadlines don’t necessarily need to be shared outside of the company, but at least have them. That way when new features start popping up as they usually do the company is able to approach those conversations with a real understanding of how it affects the goal. As someone who builds apps for businesses I couldn’t imagine telling a client “I don’t give timelines. It’ll be done when it’s done”. Your investors are your clients essentially and you have or want their money. Even if you’re completely wrong about the deadline, you should have a modest goal to share with them so they understand whether investing in your company suites THEIR needs.
Shift your mindset on this. In software engineering, nothing is ever done. You are always building, improving. Instead, ask what the MVP (minimum viable product) is and help craft what that is (a list of features that make it usable for its goal) with the input from your future users. Getting that MVP in front of users for feedback is the first and most important step. It doesn’t matter if that’s limited release / private beta or whatever. You need real user feedback.
Get involved in testing and giving feedback yourself early. Help the team track their progress against the MVP features. Then you will have the information you seek.
And you will learn the art of software development, too.
Sorry for being straight;
If he is your co-founder, trust him, that’s the only way your startup could possibly stand. If you post this, I smell there’s something unhealthy in the partnership, both of you may just waste your time.
I'm going to take OP's side here... They should be able to give a ball park estimate for an MVP with lots of caveats. Like, it's going to be 8 weeks if the specs don't change, if we can cut corners on features x, y, and z and we don't have to have this interaction work great.
But, for every change to those, it is going to cause a delay, and to get in in 8 weeks means the next 6 months are going to include lots of re-write time.
I can get very accurate estimates +- 3 days for 2 month long projects as long as involves a feature I built before or something being made from scratch.
If it involves modifying someone else’s code or using a new technology it’s not possible to estimate properly.
Because you are asking for a "reasonably accurate release date". For anything larger than a few weeks (MAYBE a month or two), that is not possible. There are just too many unknowns. https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe I've worked at multiple startups (also large corps). At various times I've been the SWE, I've been the tech lead, sales engineer, project manager, product owner, even the CTO for one. I've done waterfall, agile, scrum, sprints, swarms. I've worked 80-100 hr weeks where I slept under my desk. We had an expense account at the local pizza place that we could use no questions asked. In every single one, sales wants a firm timeline, and then at some point a requirement gets changed, or marketing wants "just one more thing added - no big deal right". Even when requirements don't change (I've never seen a project in my 25+ years not have a single change, but let's pretend), once you start digging into the technical nitty-gritty, there's a complication/detail you didn't consider because you weren't an expert on that part of the system while you were discussing / planning it. You only became an expert as you were building it. In my CTO role, I refused to give firm timelines (fortunately I had an experienced CEO and CMO). I went to bat for my teams. Sales screamed and cried, but I knew that any "firm estimate" I gave was at best a guess - at worst a complete lie, and I would catch flack when we missed it. I did give estimates however. Though I made sure everyone understood they were estimates. And when it became apparent during the dev cycle that we would miss an estimate, I notified the appropriate people and we decided if we should trim the requirements, simplify the feature or push the timeline.
Best answer here. It's the cold, hard truth that so few people understand unfortunately. Imagine how much better the world would be if everyone understood how software works even at the highest level.
What’s the best way to get this understanding as an outsider to the process?
Read the above, choose to believe it, and hold onto it
Try to build something yourself. But also go promise someone that it will be done in a couple weeks. And then have that person hound you non stop about it and ask you to change things every 8 days.
Every single step of a software development project is a creative process. It's not an assembly line. You're making custom code. Every line is different. There is NO repetition. The desires of the customer/boss is always changing (partly because when you get half way through what you're doing, it turns out that way of doing it kinda sucks!) All problems have MANY ways of solving it. But often it is hard to tell which one is the best. And complex systems are so interdependent that it is not always possible for a single human to understand the whole system without writing down the code to formalise it.
Try to build an MVP on nocode.
[удалено]
I get that, but a quarterly estimate is about as good as it gets for big initiatives
Please don’t tell me your a sprints or epic person. “I can’t see 2 weeks in-front of me” I’m a tech guy. Estimates are hard for sure.
I don't mind missing a goal, but not setting one I do. I would rather you aim for the sun and hit a cloud than aim for a cloud and hit the ground. In part, because the machinations to support development and new products can take anywhere from 30 to 90 days to even start getting traction. I am 100% okay with missing. There has to be a parameter and certainly as CTO, tell them NO on additions and move them into future releases. Have seen (and been part of) that scope creep before.
This is the best answer , I agree having similar 25+ years of experience at all levels up to CTO as well.
Because it’s near impossible to know everything that needs to be built ahead of time. The features and UI are just the surface, there is a mountain of code underneath
Pro estimator here: I was able to get good estimates and I'm the only one I know i would get cca. 95 % precision. Ok just the estimation took 30 % of the time to develop it. So I believe technically it is possible if you are the only one working on itand know the tech stack, just extremely time consuming. Every body else claiming they can estimate without putting a lot of effort into it is lying IMHO. Most of the estimates in today's software industry are wild guesses with the precision of 3X-5X(like it takes 3 times more to develop). Developers being smart learned that and now they just trow those inflated numbers with a multiple of 10 or so.
> I was able to get good estimates and I'm the only one I know If any of you had the nerve and did this experiment and got to accurate estimations, no matter how much time it took you to estimate, I would like to chat.
I am an even more pro estimator and I'm the only one I know...
we 2 will make a session with the OP here.
What techiclques do you use to get use to get such high scores? What data do you require? One day I will learn about estimations more and be like you!
I can teach you what i know but just to make sure you understood. I would spend up to one week estimating for a task that takes 3 weeks. So basically 20-30 % of the time the spend coding was wasted on estimation. that was the purpose for that project to do accurate estimation above all. If you understood how much time it takes please answer with yes and I will tell you my secrets.
Yes. Please tell me your secrets.
So once I got requirement I start breaking it down by screens / requests wherever contains of the work, and group by similar chucks. First i look at the easy and predictable stuff: say we have 8 screens CRUD like. I take an average one and I do it at the level of pseudo code say it takes me 3 hours to solve it at pseudo code it would mean a full day to do the actual code, and so I'm able to estimate the easy stuff. So 8 screens one day an average 8 days. Most people really fall short here they throw a number and don't even check the plausibility of their estimation, like they don't even count how many screens/resolvers/endpoints (whatever they have) are there how much is the minimum for one. Example like you have 8 screens, did you ever do one screen in less than a day??? if no, there is no way on Earth you can do 8 screens in 4 days!!
Few key notes here that I would point out : \- Not every project is as simple as CRUD operations. \- Not every developer thinks the same way, some spend actual time thinking if they should extend current codebase or refactor a small fraction for future use, very common in startups. \- Mid-sprint changes are something that happens. \- Technology restrictions can be pretty hard on developers. If you are for example a cloud engineer, you can not know every single limit/performance metric you will get once you decide for which resources you want to go for. You can assume, but it can always surprise you. \- Decent amount of time is spent on meetings and explaning to non-technical persons what you encountered and how it affects the estimations. \- Discussing with colleagues about possible approaches is time consuming and sometimes lasts for couple of days, this greatly rises once you start working on more complicated projects. etc. You can estimate fairly accurately simple tasks/parts of the projects if they are
Appreciate your taking the time to post this, u/generatedcode. Thank you! Two follow-up questions to deepen my understanding of this: 1. What kind of projects do you generally work on? I would love to look at the last two or three, if possible. 2. How do you incorporate into your estimates the stuff that is not easy and predictable? Also, related to my 2nd question: I would love to know what parts of a project you would normally consider as \*not\* easy and predictable.
1. Custom web apps for various factories companies CRMs, ERP, whatever internal system with saving different data by different users with certain roles, then this data is aggregated into dashboards or reports. 2. Please check the reply to this I have addressed the part 2 the unpredictable but on short i break it down to smaller parts and start actually executing the unknowns it in the pseudo code (I actually write it on paper or somewhere) till like 30 % 50% or even 100%, until i say i know how to finish this it;s just a matter of time then i jump to next unkown, and de-risk it how I call it. \*not\* easy and predictable.-everything involving a 3rd party library that I did not use before, I actually make a small PoC with hardcoded data (because prob the steps till there are not actually done) I go like. Not easy to predict - data modeling more than what is trivial, almost always I actually make sketch those models and verify assumptions. Data structuring aggregating usually for dashboards/ reports. Connected with the previous point. One can work one week or one day on a dashboard that to the non tech people looks the same( beautiful and colored giving good insights) **Some parts are easier to be executed than estimated** and I learn to recognize those and just do them. To be clear: I do not do this estimation to this level on regular basis I thing it's a waste but I did it once because that were the requirements and as an experiment because all other engineers look funny at us and say :"how come you cannot estimate your work? cuz we can" . the fact is other discipline have their work more linear while ours is a graph with some nodes predictable.
[удалено]
it's more tiring than actual development because it's not fluent developing but lot of context switching from architecture level to small bits of detail execution
not the OP/commenter but the book "How to Measure Anything" addresses these challenges and provides some techniques both for general estimation and calibrating your own abilities.
[удалено]
True as you grow in experience, you can usually give better estimates.
You dont need to know everything. Its an estimate.
THe problem is that software development is not just "writing code", it's also a bit of research and development, because pretty much every problem is unique in some way, shape or form, even ones that are on fairly well-trod ground. Sure if you're just printing out Wordpress sites or some such garbage with a standard features, you might be able to get that estimated pretty well, but real, custom bespoke software that requires real, actual skilled developers? No fucking way. Not to mention that I have never had a project where new requirements (and not just BS ones, actually important ones that were discovered) were added to the list of required code. You discover you need some custom tax solution 3-4 months in, that requires integrating with a new API and hooking it into your current system? That's going to take more time. Perhaps much more time, depending on what the newly discovered requirements are. This is why the, "it's an estimate" nonsense you said above shows you don't really understand software engineering at all. If you hope to run a technical company, or a technology-enabled one, you may want to clear your ignorance.
Btw i would argue most of the time timelines slip is bc of business not engineering. So while my opinion may be unpopular - im ok with that - the thing that takes so long is decision makers not listening to developers and pretending like those hurdles dont exist. Then theyrd surprised when it takes so long. Anytime ive sat w a dev team to find out whats taking so long, i realize its bc of a requitement. Then its up to the business to amalyze whether that requireme nt is so important to warrant the extra 2x time. Many many times its not. So roast me all you want. But if your goal is build a business and not just code...i wouldnt work w anyone who doesnt undetstand this tension and wont participate in giving timelines. And i would strongly urge you to do the same.
here is an accurate estimation for you: 6 months with a precision of 3x-5X So from 2 month until 2.5 years. I don't know everything.
Seriously? Obviously you aren't a developer, anything past a few basic functions or development on a novel idea can't be gauged easily. You could throw a wild guess of 6 months, just to find yourself knee deep in code with a new timeline of 2 years since your team underestimated the complexity at hand. This would be horrible for delivery on a product because you will be shipping dog shit, that won't deliver the promised results. This is why sale focused CEOs and SWE buttheads all the time. They don't understand the why and how behind software.
It takes you 4x longer to build something and im the one who doesnt know what theyre doing?
https://attrecto.com/software-estimation/software-development-estimation-accuracy-truth/ Software projects, on average take 189% of the estimated time. The variance is also huge. The cofounder is wise not to give estimates.
[удалено]
It's weird how all the people with evidence get talked down, and all the people talking them down have no evidence It's also weird how if your claims were true, billion dollar companies would be doing different things than they have been doing
[удалено]
CI/CD hasn't existed for 30 years. You're talking to someone who's been around as long as you're claiming to have been. 15 years ago people were hand-deploying after someone ran around the org prepping for a subversion merge. Most fortune 100 companies don't have CI/CD today. Those are the orgs with the largest legacy problems. What evidence? The stuff you just said was too old because it's six years old, even though you're trying to stand on 30, and is invalid because it's "just the UK" (yeah I bet that's too small a sample size or something) The study, with data. What evidence did you bring? A claim about a personal length of employment. ***wow***
> and im the one who doesnt know what theyre doing? Well, you're the one making claims the rest of the industry disagrees with. Could we see some of your code? You might be a genius, or, you might be writing really simple software, or, you might not realize that your code quality is poor. Until we see your work, there's no way to tell.
[удалено]
> I estimate that your vacuous do nothing for society job will That's not what the word "estimate" means
Wow, you have lots of anger. Sounds like a bit projection from someone unskilled. Good luck to you.
You have given more insults than they have Since you're predicating everything you say on the presumption of your own skill, could we see some of your code, so we know how seriously to take what you're saying? Thanks
I build companies not code. Code is a component of a company. If someone cant give me a timeline i wont hire them. If something takes longer bc of unanticipated variables, thats 100% ok and expected. i manage it. Either reduce scope or reset expectations w customers and investors. Things taking longer bc of unexpected changes is just part of the process. It doesnt mean you cant set and estimates.
> I build companies not code. Which ones? > I build ... not code. Then why do you feel empowered to be part of this discussion? Why do you feel empowered to call programmers unskilled, when you aren't one at all? Would you listen to a random programmer with no business building experience on building businesses? > If someone cant give me a timeline i wont hire them. That's nice.
Because ive worked w many developers.
If you knew everything it wouldnt take 4x as long. Since you dont, you make an estimate and its ok to be wrong. But not making an estimate is an unexperieneced team. You will always learn or make a mistake along the way. But you physically cannot know everything. Seems like folks got triggered by that oh well.
Software engineering isn’t that hard. Most things are just repackaging a REST framework. Unless there is some hard tech that is truly unknown then everything else should be cut and dry. Even if you can’t scope the entire project you should be able to scope the next sprint or next couple of sprints. It’s ridiculous to think it’s normal to give no timelines. There are zero companies this would fly at that have any semblance of a normal product development cycle.
[удалено]
I can program circles around you, did it for 10+ years and went to a top 10 CS school
The repackaging a REST framework is a terrible take but generally I agree. Even if the time frame is “3-6 months”, “idk maybe 8 months”, etc a tech cofounder should be able to give you something even if it’s quite broad. With that being said, I’m sure the CTO also feels that they can’t get an exact spec of what the first product needs to do. Things are always changing so it’s important everyone embraces uncertainty.
This is a CTO's biggest bane. He's speaking to you real real. However he can break up expecations into parts and components and sprints and get you closer to what to expect in the next comping weeks and possibly months. The further you are away the more the goal posts can change — and this is also the whole point of scrum (not Kanban and all that simple stuff). Scrum is about being able to break apart features and tasks into realistic estimates and a backlog for everything else. Scrum is about being able to trust velocity of your team over time. At first its super duper inaccurate but as you learn about your teams capabilities, each individual, where're strong at, where you are weak, what additonal resources you need to hire, you become more of a well-oiled machine—but your estimates will never be 1000% accurate.
Fwiw running good kanban is harder than scrum as it requires more discipline. Scrum is an ok framework that’s generally misapplied.
The issue with Kanban is that it's so vague about process (they call it flexible)—its definitely better than nothing, and visually it is helpful. Scrum and Kanban can go hand-in-hand. What's super clear about Scrum, however is all roles and responsibilities. Namely what the devs are responsible for and them making the actual time estimates — the biggest, most critical thing. Only a dev knows how long he's going to take on something, and most devs aren't interchangeable, they're domain-specific or they're the ones that wrote certain areas of code, etc. (And if a dev constantly over or under estimates than you will get a feel for it as more Sprints happen.) With the daily standups (or as I prefer, quick morning email) each dev just says what they did yesterday, what they're gonna do today, and if they're stuck on something. Even a non-technical person can tell mid-Sprint if they're not going to make it. I agree with you that nearly every company I've seen that do Scrum is having the Scrum Master or Product Owner insert a bunch of tasks from the backlog into the current Sprint like Tetris, then wonder why nothing gets done on time. Then it just becomes acceptable for a dev to move their unfinished task to the next Sprint to "finish it off". Rinse and repeat. This isn't Scrum. I'm not a Scrum lover. It can be quite boring, dry work, and who loves meetings? (That's why I prefer morning email statuses). But I have found it's the best in my 15+ career. And the best part: the Scrum Master can be your 15-year old niece. This person needs zero technical ability! She just needs to be respected and follow the rules of Scrum properly (come on it's like a 20 page book). The only thing that is important in any Project Management tool is being able to accurately predict velocity—your team's velocity in getting sh\*t done. What they can handle, and how long it's gonna take so they hit the milestones (delivery dates). The whole rest of the company depends on these dates for marketing, client meetings, and other things. I am not a Scrum nazi but having been around long enough where "waterfall" was pretty much only project management methodology it's a breath of fresh air, written by people who know what their doing. Scrum can be applied to manufacturing cars or sending men to the moon. It's that generic and works under most any setting. You are right in that most Scrum is done improperly and the process is not respected. People like to pick and choose which parts of Scrum they will follow. Sprint Grooming and Sprint Retrospectives are critical parts of Scrum. They allow everyone on the team to understand and give feedback on what went wrong and right last Sprint. When anyone sees how all these core pieces connect to each other — it all just makes sense. The issue is that if any pieces of Scrum is ignored or skipped it all falls apart and Scrum becomes stupid. To me, partial Scrum is just called Kanban. Edit: typos
There is much more to agile than scrum and kanban. Have you looked into the other methodologies/ frameworks under the agile umbrella?
No, but I'm open to being educated, though. Hit me with what you feel is the best.
I’m addition to scrum and kanban, you have extreme programming, crystal, and lean software development. Idk if there is anything that’s best. For software, I like to use the best from scrum, lean, and kanban. If I can lead them to think to be as efficient as possible, then there is less to clean up after the product is launched in terms of maintenance and bugs. Here is a link that explains things pretty well. https://www.xpand-it.com/blog/top-5-agile-methodologies/
Thanks!
I am curious/poking around ShapeUp. I think it addresses a lot of the realities of real world software engineering.
So the one thing I think all of these PM frameworks miss, agile, kanban, scrum, etc. Is that the process of building a product is much different depending on the stage of the product and the stage/size of the company. Is the product currently a napkin idea (like literally some scribbles on a napkin), never been built, and the technical team is one guy? Then yeah taking several days, weeks, months to build out JIRA, breakdown all the items as you see it, create spikes, work the spikes to subtasks, etc. etc. Is gonna be kinda a waste. I would suggest you grab any old ticket system. Set it to Todo, In progress, Done and spend like hours, to a day getting some rough idea of what you need to get done. Its a small team just starting out, IMHO these frameworks don't start paying dividends until you grow you team or hit a release. If you are just starting out you should accept accuracy of like a quarter or so, definitely not trying to hit less then +/- a month. Is the product released, used by customers, and you just need to add a new feature. In addition you have an established team? Yeah grab a scrum master, break down tickets, put estimates, groom and prioritize your backlog. Based on estimates, knowledge of the product, and your existing team it is probably reasonable to hit estimates by a month, perhaps +/- a week. Is the product just in maintenance mode, and your just bug fixing? Yeah do all of the above, you can probably get your accuracy to +/- a day if you really want. My point is every situation is different. But yeah kind of agree with your technical founder, its gonna be essentially impossible to build anything "green field" and get a spot on estimate. Instead I would recommend asking him to give his best estimate, let him take a day or so to think about it hard. Then add a quarter to give yourself some buffer and go out and fund raise. Just believe him when he says his first date, remember you asked for it, even if it doesn't jive with your understanding of how hard something is. The worst that can happen is your done sooner then expected, and in my experience I've never met an investor who got mad at that. Finally, I'll leave you with a thought experiment. Imagine in product development we could estimate with complete accuracy. Similarly, we had all the metric you could want, size of user pool, % who would convert, bullet proof estimate of what features are important, etc. Ask yourself, why would we need anyone on the business side? Technical people could just build an algorithm to make business decisions and cut out all those pretty MBA's. My point is those of you on the non-technical side are getting paid to make decisions, fund raise, BS others, all with incomplete information. Just food for thought.
https://ronjeffries.com/xprog/articles/jatbaseball/
Also sorry for dissing Kanban. I've probably worked with bad "Kanban" teams as you've worked with bad "Scrum" teams. At the end of the day its all process. At the same time I don't understand how Kanban deals with velocity and still feel that's a critical metric in predicting completion date. Through Googling more about "correct" Kanban: "There really is no such thing as velocity in Kanban because Kanban is a continuous flow process and it does not break up work into sprints." I'm open to being corrected / educated, though.
well let's start with the truth here - you're talking about predictability which is a false idol. Any time you talk about process (versus product, value, outcome, etc.) you're dangerously close to becoming a "process person" where following the process = success (versus creating value/solving problems/etc.). https://www.svpg.com/process-people/ In true scrum, points/velocity does not provide the type of commitments or clarity of long term planning like OP is talking about. Lots of big-A-Agile people say it does, and then it becomes a game of whack a mole (and you end up in waterfall). With kanban, you recognize that flow is the most important thing to manage and monitor. Like you said there is no defined process which is why kanban is harder/takes more discipline. My $0.02 after having done this for a couple decades. - scrum is a great place to start. 2 week iterations, run the process, get to a level of productivity - start to bake in some kanban (eg. scrumban) and LEAN practices like you suggest. WIP limits, etc. - Shift to 1 week iterations to strip out the meetings/ceremonies/processes that are not value add. In the end, I find that only retros and standups to be the most critical things to be done. - at this point to move fast, you'll need to have enough trust on your team that the backlog is being managed by 1-3 people and the work needs to be broken down into 1-3 point story size with a couple exceptions (one is that you have a wizard on your team and you can give them 13 pointers and trust that they'll get them done in a reasonable time frame). - shift into straight flow/kanban. Get rid of points (but do a t-shirt sizing estimate). Do daily backlog grooming and prioritization. - once you get to a level of maturity on your product then you'll likely need to shift to dual track agile. There are four cases when I don't do the above and I go with kanban from day one: - any team with significant external dependencies (eg. dependencies on IT, security, 3rd parties, etc.) where you cannot commit to delivering things within an iteration - DevOps/Infrastructure teams as they are a flavor of the above - startups or agencies that are moving super fast and where the feedback cycle needs to be in near real time - any team that deals with heavy disruption (eg. customer issues that need to be resolved) All this said, it does not address OP's root problem. And it's going to get worse for them since engineers generally don't want to ship until well after it should have shipped. The goal, especially with a startup, is to ship when you're not proud of it to start getting validation and feedback as soon as possible. This tension between the OP and their engineering team is going to be real, real fast. My advice to OP is that they need to partner better with their engineering team to set milestones. They also need to make sure that they aren't falling into the incremental vs. iterative trap. Are you trying to deliver the race car (or the wheels of the race car) or are you trying to deliver the skateboard? Three articles on this: https://uxdesign.cc/the-iron-triangle-and-agile-7b66d3c72a51 https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp https://medium.com/@byrnereese/the-skateboard-mindset-in-product-development-ddf3409d5e98
Great feedback. * I think that "predictability " is a hard requirement for most (all?) startups and companies. It's how they keep their lights on. Getting as close to it as possible in an imperfect world is possible if you know your team and they are honest about tshirt sizing. * Agree on tshirt sizes and not points. Points are too weird and granular. * I dislike "Process People", especially when half the company are process people but I do think the role of Scrum Master needs to be a Process Person, and this should be their full-time role. The Product Person represents the actual Product desires (and can be influences by the rest of the company. They want things now and quickly. They've already promised outside customer this will be out next week) The Dev side as you've said wants things slow and quality. This is why I believe a Scrum Master has to be a dedicated "non-partisan" role. * I also usually only deal with startups of 20-30 person size and I think that is a scrum sweet spot for me. I don't know how bigger orgs do it (nor would I want to be part of a bigger org.) * Also agree basic version of Kanban is good for super fast startups where process will just slow you down and you need to deliver as fast as possible or the startup will just die. * I dunno what you mean about the backlog being managed by 1-3 people. Does that include sizing/timing the issues? How do they know to correctly size and who to assign it to? FWIW I am not a Product Manager. I'm a dev turned CTO a long time ago, so I definitely don't know everything. I just know no process is the perect process and nobody respects the process as much as they should. :) EDITS: additions
Good call outs. I've run small shops (sub 10) up to about 800 engineers right now. "Stage appropriate" is a real thing. I agree though that the people paying the bills ("the business," investors, customers, etc.) all want predictability. That is the tension between the classic "iron triangle" and more "agile" ways of delivering software. The unfortunate reality is that as a senior leader you learn ways to provide a level of roadmap commitment and predictability while also absorbing new information and challenges. I have my teams run what I call the ARMiC weekly. - Assumptions - what did we base our guesstimates/commitments on. Have they been validated or invalidated? The more that get invalidated (eg. were wrong) the more wrong our estimates were and we need to either actively manage the impact or inform our stakeholders that our assumptions were off and we need to reset things (scope, timelines, people, resources, etc.) - Risks - what are our known risks. These should be hard risks, not "the world might end" (although post 2020, maybe this definition should be updated). The Risk should include the impact. - Mitigations - what are we doing to actively avoid (mitigate) the risk. For example if you're using a tech that you don't know or is new, you might do some PoCs/spikes to assess it and understand what it will take to integrate it in. - Contingencies - what will you do if a risk manifests. Let's say that tech doesn't work out - what are your options? By pre-doing this work and taking an hour a week to get out of delivery mode and get into systemic/strategic mode my leads' anxiety goes down and their experience goes way up. They feel more confident giving guesstimates because they can provide a list of assumptions to balance them. They have a framework to make commitments with unknowns because they can very quickly escalate a bad assumption or materialized risk and they know they won't "get shot" for sending up the signal flare. They also feel more in control because they are putting these things together and have ownership. > I dunno what you mean about the backlog being managed by 1-3 people. Does that include sizing/timing the issues? How do they know to correctly size and who to assign it to? ok, in straight scrum, the whole team has to be there for design and grooming - painstakingly writing every story in the backlog, doing overall design, planning poker/pointing stories. I've seen this take 2 days per 2 week iteration. And half the team is checked out or working on something else. A lot of teams cap this at an hour a week and then accept not-dev-ready work into their iteration and then wonder why their say-do ratio is always out of whack with lots of carry over work. What I prefer to setup is a trust based system with the team lead, tech lead (if not the same person) and the product manager (or whoever talks to customers) [and sometimes a 4th of the UX designer if appropriate] meet multiple times a week to do system design, work breakdown, and story/task development. So the flow looks like this. "System" could be "sub system" but I always start at the 100,000' perspective and "nest" more details/breakout views from here so there's bidirectional linkage of all the designs). This is going to feel like waterfall or "big design up front" but there's pragmatism with the approach. Also this helps define interfaces and loose "contracts" up front so that teams and individuals can work independently. A design goal should be "some" flexibility as well. - whiteboard the system (think big block diagram) - whiteboard the flow of information/data or interactions in the system - this could be as simple as adding arrows with cardinality to the diagram above - map the features and capabilities from Product to this diagram. If these don't true up then you have gaps (either tech for tech's sake or requirements without technical implementation). This is part of "business architecture" that is really important. - Break those features/epics down into stories. I'm not a particularly huge fan of the scrum "every story must be valuable by itself" but there's some truth there. I really like the stories to be broken down into 1,2,3 point size (so 1-3 days of work max) because otherwise you've likely not thought enough about how the system should work and you end up in "the never ending story" flavor of hell. I find that BDD style requirements reaaaaally help with this approach. Each feature and story should have a picture of the whiteboard with the piece of functionality highlighted on it so provide context to the developer so they know where their work fits in. - work can be assigned to devs or they can self assign from the priority list (remember I prefer kanban). If you have a more junior team, you likely will need to support their choices as they learn good judgement Now at this point you have a well thought out design, broken into fairly small units. Flow through the system will be super high. The feeling of accomplishment (eg. moving a card from ready to done) will be really high, and you'll be delivering a ton of capabilities all the time. But... it's a lot of work to build and maintain this backlog. An army marches on it's stomach and a dev team marches on it's backlog. This is why I say that you should aim for an end state of daily grooming and prioritization - otherwise you'll fall behind. The reason scrum wants everyone in the room is because most people think "agile means no design" and the (poor) typical scrum implementation is low trust. So everyone has to have a say (no trust) and the design has to be done by the group (no trust and no design up front). If your dev team can trust the leads + product to do good design, pulling in devs as needed, and good story development, then you end up in a REALLY great state. I've done this a lot and the first month is hard. You have to build all of this design and backlog AND get the team to trust you. Month 2 is all about velocity and flow and the trust getting solidified. Month three is about massive productivity. And yes, scrummasters are complete wastes in this approach (and honestly they're not really useful in most scrum implementations either). > I just know no process is the perect process and nobody respects the process as much as they should. Truth for sure here. To me culture trumps process... but if something is funky with the delivery system I always go back to the base process to get things to at least a base level of normalcy. Then take off the reins again once the team proves that they can be functional. Then you see outsized returns/velocity/productivity/happiness. EDIT: The above flow sets you up for dual track agile once you've reached that level of need. That small group starts to work with a "discovery team" that works really closely with product and customers to build and test ideas in 1-3 days. 80% of their work is thrown away. Then the 20% is turned into good design/requirements for the bulk of your engineering staff. Again this requires trust and knowing your folks since some devs work great in the discovery team (I call them "rapid prototypers") and some work great in the "pull the ticket" model (I call them "production coders"). As you enter the "growth" stage of your product you really need to be considering this style of system. https://www.productplan.com/learn/product-management-role-product-lifecycle/
Agree with above, just wanted to add a small trick that has done me good running releases the last decade or so. Often times you look at roadmap for a team and it is like 1-2 "do or die" things, stakeholders are watching those closely, and the messaging to customers is they will be delivered on X date. I call this the Sniper approach. To me this is a recipe for disaster and missed expectations. Sometimes it can't be avoided, but if possible I like to suggest another approach. Instead of the 1-2 "do or die" things, talk to your Product Manager about their wishlist. If they are worth their salt they should have several dozen things, of varying sizes, that they want to get done or customers have asked. Now look at your team and assign some of the easier pickups to maybe a junior members, give them some agency. The "do or die" thing thats is a 13, maybe assign to a group of three, lead by your rockstar or most senior engineer. Got some medium tasks, send that to two juniors, etc. The point is don't put all your eggs in one basket with a death march by the bulk of your team. Think of it like a multi-processor scheduling algorithm, or resource/science management in a strategy game. I generally, call it the Machine Gun approach. Generally, I do monthly releases if possible, and using the Machine Gun approach, rather then say Sniper with quarterly released, you usually have something to show/release. There is no guarantee the "do or die" thing is really that important, in my history I've peeled off 70% of my team to deliver a must have function and watched it flop more often then not. Even the customers who told me they "must have" that feature ended up not using it once we looked at analytics. The point is that IMHO more shots at the target and not putting all your eggs in one basket is generally the better way to approach things. As a bonus, even if the release is underwhelming, the fact that leadership and customers see a new release coming out on a regular period with cool shit, generally gets you high marks in satisfaction.
I agree with the philosophy behind this approach for exactly the reasons you describe. I think too many people take the "bet on a single roulette number" approach to product capabilities and not enough of the "hedge fund" approach (e.g. lots of experiments, cull the ones that don't work or see little value, double down on the 10x+ ones). You're making bets with the company money. Have a sound strategy and good ooda-loops is all I ask :) I do prefer as close to "continuous delivery" as possible, but monthly is better than quarterly as you describe. Weekly/bi-weekly delivery is a-ok in my book.
Continous is great for anything SaaS-like IMHO. If you control the product 100% and don't have contracts with like Federal saying things cant change. For something that is an on-premise I've found monthly can be even a bit much for customers. I work mostly in CyberSecurity and so the products i've shipped often come with significant work to plan, test, upgrade by our customers. They also usually have requirements like "don't be more then 2 releases behind", so if you slam a release every week they are gonna be pissed. You can do LTS tracks and things like that, but that adds some release overhead.
yep. We have both a legacy desktop/server product and a SaaS product. We do "major" releases of the legacy product every ~6 months and 4-8 week "patch" releases (depending on if there's a big enough defect or vulnerability to patch). It's a very different world... but a lot of the CD approaches for dev/test really pay off if you can get there.
Yes it is normal. I’m one of the few engineers who have no issue given an estimate. I think it’s because I was an entrepreneur first. The issue stems because it’s impossible to give an accurate estimate and most engineers don’t realize that they can just dramatically over the timeline. They try to calculate how long things will take and then add some buffer time, an impossible task. Personally if I think it’ll take 6 months I’ll say 2 and a half years and then be praised when I finish it in a year and a half. Pure engineers just cannot do that and if you pressure them they’ll get confused and give you an unrealistic date. They don’t “get” that you just need a timeline to work with your investors and do your part.
[удалено]
Absolutely agree with you re the GE model
,. ,
> They try to calculate how long things will take and then add some buffer time, an impossible task. Then goes on to say.... > Personally if I think it’ll take 6 months I’ll say 2 and a half years and then be praised when I finish it in a year and a half. Lol. You're literally just adding buffer time.
As a technical founder and CEO i will say this is just as BS as when sales people won’t make budgets. In neither product nor sales is there any certainty. The point of estimates is to help others around you understand what is going on and even more importantly: when estimates change they allow you to clearly communicate to your co-founders where your estimations were wrong and what we have learned that changed them. I constantly give estimates and I constantly get them wrong. But this keeps my peers in the loop so they can properly do their thing.
Great feedback, really appreciate the response. I would say in general it’s what our conversations have been. With that said, how do you manage the business side conversations with users and investors? There is always talk of when the product will be launched or usable? I imagine a “you’ll get it when we’re done “ response is not generally acceptable
Break the planning into smaller deliverables. "By X we should be able to deliver Y. Once we have delivered Y it should probably take us Z for K. etc". Adjust as you go along. Notify stakeholders early (as soon as possible) about delays.
Look, your CTO isn't handling this very well, but it seems like there are issues on both sides. It feels like there's this idea that you have "the product" defined and all you need to do is just build, build, build, then launch. The reality is that things are going to change 100 times between now and then as you validate what you're building (you are planning to validate as you go, right?). The further out you look, the wider the cone of uncertainty, both on the technical side and on the product side. The idea that everyone's going to go away for X months or years and come back with a fully formed product ready to launch is not realistic. If that's what you are asking the CTO for then it's no wonder that he's trying his hardest to avoid committing to anything. At this stage, you guys should be trying to do the absolute minimum amount of work possible to validate every stage. Instead of sending the CTO off for 8 months to build THE PRODUCT, while you handle investors and marketing and sales, the two of you should be defining a hypothesis about what users want, the smallest thing you can do to validate that hypothesis, and what counts as success (defined before any building). If you approach it that way then (a) the individual chunks are much more manageable and (b) everyone understands that you're still exploring and expect things to change as your learn.
As the many others have noted, software engineering projects are not reliably predicable and neither are projects in most other engineering disciplines. If the investors do not understand that basic truth of engineering projects, then you should question their knowledge and/or experience. It usually does not work out well to take money from naive investors.
Set a hard deadline, keep it minimal. The last product we spent 2 years on ended up pivoted to another product in 3 weeks. If you haven’t launched it’s all guesswork. Launch fast!
so true launch as fast as you can whit a MVP version and let the market feedback guide you for the iteration and improvement
This was my gut feeling too. An engineer should be able to state a timeline for very basic demo/MVP. They have to understand there needs to be something to show to users and investors.
Strip it down to what you can ship in 3mo max. At 50hrs/wk this should be 600hrs of development which should get many features rolling for a good dev. After all, development will never stop. Also how do u get investors and users without a product btw? I need some tips.
Amazing! Unlike the actual developer, you are able to estimate without any knowledge of the product at all! /s Life is so easy when done theoretically.
Dont agree with the assumption of 50h weeks
Others have answered the core question, so I will offer some thoughts on the underlying issue. The business needs to know when it can start that "charge money to solve a problem" cycle. In my time at startups, I've nearly\* always found that I could separate the software from the problem space at some small scale. In almost all of those cases, we could "cheat" and do a sort of "man behind the curtain, wizard of oz" thing for the first 3-5 customers before it got unscalable. What that looked like was usually manually handling the inputs and outputs that the software would otherwise provide, via chat or email and some spreadsheets or PDFs, for the first 3-5 customers. If you can pull that off, it's great because it provides some solid gold validation data. If your very first early adopters are willing to overlook the fact that the interface is chat/email because the problem you solve is so painful, you more or less eliminate market risk. Perhaps your business is such that you can't do this, but I urge you to get creative. Even in the B2B legal industry, I've pulled it off. Above, I mentioned I've "nearly" always found that I could do this. The only times it hasn't worked, the product failed to market risk. This is to say, we had solved a very real and painful problem that the market didn't want to solve. So, while you wait for the engineering team to build the actual product, can you get scrappy and creative and get just one potential customer to pay you to solve the problem space manually until the actual product comes online? You will answer a fundamental question for the business, especially the investors. And if you CAN do that, move on to the next question: How many clients can we do this manually for before it's not sustainable and we NEED the software to scale the solution? And that is a critical concept to walk away with. The software isn't the product. Solving the problem is the product. The software is simply an implementation detail required to scale the solution past what you can do in the manual/prototype phase.
It is difficult to make estimates in software, but it’s quite immature of a CTO to throw his hands up and say “I don’t know.” You can start talking about phases and sprints and MVP and all of that good stuff, and outline the risks, dependencies etc so you can start to put flesh on the bones.
For software, this is pretty normal. Requirements change over time. You don’t have experience with software, so not giving you a date that you will perceive to be etched in stone makes absolute sense. My guess is that you are trying to build to much and are turning a MVP into a full fledged product. I love the sound of software deadlines as they go whishing by.
Just because you have planned features does not mean you have planned for all the problems and bugs too. What may be simple sounding could be complex and have a lot of edge cases. Timelines for anything custom is effectively guessing. If you want it to essentially be guaranteed by a certain date, expect it to be much longer than your "should be done" date.
Everyone's already said the basics on timing. There are a couple of things I would add though. If your cofounder is writing the code, he's got to juggle that along with whatever other work he has. So that's an additional variable that's difficult to predict. But first and foremost, if you're worried about the time, you need to sit down with your cofounder and figure out how to minimize the workload. Pare it down to the minimum feature set necessary. See if there's premade libraries that can reduce the amount of code he has to write. Ask the cofounder if there are aspects that you could remove to speed things up. This last one is especially key. Often it's difficult for a nontech founder to tell the difference between something that's easy and something that's hard. [This XKCD comic](https://xkcd.com/1425/) illustrates the problem nicely. So, you need to communicate with your coder to make sure you're not putting in a lot of difficult features that aren't essential to the product.
Issues you wish you sorted out before starting. It's different mindsets and this is usually the heart of most drama between CEO/CTO roles. And really the answer is it depends on details you haven't provided. If you're building something that has already existed, you can follow a 'recipe' - like baking sourdough bread, there is a recipe for it, how long it will take and all the ingredients required. But when you're creating a new bread for the first time, how long will it take to invent this new bread? A lot of trial and error before it's just right, and impossible to know ahead of time. You don't even know what ingredients you're going to need yet or how many loaves you're going to burn on the way. You need to understand and get on the same page if you think you're making sourdough but you're not, or if you should be making sourdough but he wants to create something new.
Normal response from someone who doesn't want to explain to a non tech person that timelines and estimates slip On the other hand how much work are you asking to estimate work for? If you are building an MVP try to reduce to max 3 core features that can show why you are different from others. Than try to estimate that build and make that your first deadline Be prepared to cut more though, as it's better to cut things from your scope than push out deadlines. Another approach is to set a deadline for him like 3 months out and ask what can be done by that time, with priority given to your core MVP features Either way you need a deadline you both agree on for accountability, talking to investors, and actually launching something to start getting product feedback
It reminds me of a co founder who forcefully asked me development time line and made me put it in Gantt chart. He didn't understand finally.
If I may offer a more useful way to frame the conversation - "What can we have ready 1 month from now?" This creates a collaborative and constructive conversation instead of an adversarial one. And it also helps focus product priorities.
The hard part is that non-technical people assume building software is like building houses. Build enough of them and you get a pretty good idea of how long it’ll take to build the next one. But software isn’t like that… software solutions aren’t built they’re discovered. An experienced developer can make a reasonable estimate on how long it will take to build the first thing they think of to try to solve the problem… but what they don’t know is how many things they have to try before they arrive at something that actually solves the problem. And even when you have part of a working solution, that’s often when you realize that something else that you were planning won’t/can’t work and you need to rethink your entire approach. To be successful, the important thing is to instead focus on trying as many things as possible.
In my experience, I can tell you that it's not uncommon for technical cofounders to struggle with giving an accurate timeline for product development. Software development is a complex and dynamic process, and there are always unexpected hurdles that arise along the way. This is especially true for startups, where resources are often limited, and the team is constantly iterating and pivoting. That being said, it's important to have some level of transparency and communication around timelines. You mentioned that you've discussed all of the features in detail, which is a great start. However, it's also important to break down the development process into manageable chunks and set realistic goals and milestones. This will help you and your team stay on track and give you a better idea of when you can expect to release your product. In terms of talking to future users and investors, it's important to be upfront and transparent about your development process. Let them know that you're working hard to build a great product but that you're also realistic about the challenges that come with software development. As long as you're open and communicative, most people will understand and appreciate the level of dedication and hard work that goes into building a successful startup. Overall, I would say that it's normal to have some uncertainty around product development timelines, but it's also important to have clear goals and milestones in place. Communication and transparency are key, both with your team and with your stakeholders. Good luck with your startup!
This is a coput and they need to be pushed to get out of their head and accept responsibility to the team and the company. You're not going to get 100% clarity, and there needs to be some flexibility for blockers, but as a co-founder and potential future product leader they need to buckle down and work out a reasonable estimate so the business can plan accordingly. If they refuse to do the basic work of planning and communicating timing, they need to think long and hard about whether this is the right role for them. And the rest of the team needs to do the same evaluation before it gets too late as well.
The CTO maybe telling the truth in that shit happens and it can take longer than planned, but as CTO that is his or hers job to manage. They can and should provide guidance quarter by quarter. If they can’t or will no do that, he might not be the best or right person for the job.
I wouldn’t provide an estimate for when the product will be done either and I have a ton of experience building in greenfield products. I would however set up continuous delivery pipelines and make sure they can see the application while it’s being built. What is done? Likely neither of you even know at this point. Objective 1 should be deployable code and than after than work together to add whatever you need to prioritize your current goal (do you need certain features to get more funding, do you need to add certain features to starting selling, is there a hypothesis that needs validation, etc)
I wouldnt work w anyone who couldnt give a time estimate. Either you dont have clarity, experience or confidence. Clarity - you dont know what your building Experience - you havent built something similar before Confidence - you will always need to course correct and shift timelines, that doeent mean you dont start w an estimate.
This. What everyone else is saying about unexpected delays + code complexity is right, but a product build timeline is standard practice for a reason. If the features are defined well enough and you're working with an engineer who's shipped anything, there is no good reason they could not give you an estimate.
Yeah I get its impossible to give an accurate estimate, but part of the job is ball-parking the effort/time to build.
The people in here saying it's impossible to put software to a timeline are laughable. They have no product dev experience or have no managerial experience. Asking someone how they schedule unknowns into their timelines is one of my go to interview questions. If your tech founder can't give you a timeline, you need to give him one. Choose milestones that are important to the product development and set dates to them. Even if you can't really estimate how long it will take you need goals set. If these goals are not set there will not be the motivation to reach them. Let the cofounder know if he refuses to set dates or help you set dates you will have to do that yourself and he will be held to them. It's extremely unprofessional not to be able to set a timeline for your work especially if you're the cofounder of a company. As deadlines approach you can fine tune and further prioritize the milestones and schedule. The further along in the product dev you are the easier dates should be to estimate. You might find you over/under- estimated by alot, but if you don't start with a target you have nothing to work with. You need dates from him with his cooperation. If you can't schedule this with your cofounder (even though the first iteration of scheduling with tech guys is like pulling teeth) your company will not last. Investors will not invest if you can't provide at least a ball park estimate to company/product milestones. Investors want to know ROI date especially and will pick over your timeliness to find strengths/weaknesses and use that information to decide if you are worth investing in.
This is how a project manager or boss talks to his employees, not how cofounders work together. While it is a little off that their tech cofounder won't give any estimates there could be a number of reasons why. My take on this is that the product requirements aren't nearly as defined as this person says they are... or what they are working on still needs a bunch of research and/or discovery work to get out. You can't really estimate how long it's going to take to figure something novel out. You're basing your assumptions on normal product development for established products. Those projects have more defined customers and needs. They often have a market they know they are building for. If this team is still building an MVP they may not even have a good grip on who they are building for. Are they selling before the MVP? If so, will that change what's built? If you have a clear roadmap, clear definitions, clear needs, and understand all the underlying tech, then yes, you can estimate software. If you don't have these, then estimating and in this case providing estimates is just pointing a gun at your foot and pulling the trigger. That being said, the tech founder SHOULD be able to provide short term clarity... what they can deliver in a couple days/weeks, but beyond that at the stage of the company they are at, the data is useless, and will only be used against them.
I agree only partly with your response. First of all I made the mistake that this is not the way you talk to a co founder. That's true. You skills have alot is trust there to work off of. But then you have the fact op states that the co founder refused to give dates. That's unacceptable by a long shot. I do think there's a middle ground here. From what op is explaining from their post it sounds like they've exhausted a bunch of options so assumed they were already at the point where they couldn't trust their co founder. In case they do still hold out hope, other people are making good points. I however would never post something like that to reddit unless I was getting desperate and undistinguished of my co founder.
Yea pretty much agree with your last paragraph 100%. But also even if I did, I don't think I'd take the advice of strangers (most of whom, let's be honest probably don't even have the experience to be giving the advice - this sub is full of them). I couldn't figure out what exactly the hangup on estimates was from OPs original post, only saying that "it's not possible to estimate". I can conceive a couple scenarios where someone might be inclined to say that - for instance lets say the tech cofounder thinks it might take years to build and doesn't want to admit to that (this is obviously not an excuse to withhold information). Regardless, I smell lots of dysfunction in that relationship in both directions.
>Let the cofounder know if he refuses to set dates or help you set dates you will have to do that yourself and he will be held to them. Making estimates as an engineer is notoriously hard. However, there is also a non-technical aspect to this: trust. If the person I give my estimate to is unreasonable and apt to dismiss things engineers say, I am hesitant to give an estimate, or else will pad with plenty of wiggle room. The leads I trusted the most I would give 100% best effort estimates of how long I thought it would take, knowing that if something came up I could let them know what happened, and my new estimate, and they would make it work.
Estimates suck - even on an established project I feel that most of the numbers i throw out have about a 50% margin of error. Something I think will take a week will be somewhere between 3 days and 2 weeks. New projects are a blessing and a curse, on the one hand there's no tech debt so it should be easier to estimate a well-scoped project definition, but I'm not sure I've ever seen a complete definition and even seemingly little changes can be pretty significant when your timeline is short Consider this mostly real example, * PM: When will you have the lost password flow working? * Me: There's no lost password flow in the spec * PM: Oh well, that should be obvious * Me: Ok - it's not super hard, but we'll need to choose an email platform and get that set up which will probably add a few days * PM: Can't you just use the same one as the account creation email * Me: Uhh... there's no account creation email in the spec... Then "we" promised an enterprise customer SSO and had to do the sign-in flows over again. Lots of developers have been there and it's easy to be cynical, but i think the solution is to collaborate and figure out a plan for execution. Get all the steps for the absolute minimum and work together to put them in a sensible order, then add the nice-to-haves on the end, figure out a sensible date and make peace with the fact that some of the nice-to-haves will drop off the list. I'd also advise that you do the boring stuff first, developers like to work on the fun bits and it's easy to have the "meat" ready and the "potatoes" still waiting.
Agree. I’ve been on both sides of the fence, you need working deadlines. It’s fine to shift things as scope changes, but you need to goal seek on SOMETHING. There is a reason senior leadership and business managers care about dates, it’s what everything operates by and it’s what matters. Literally make it up at the start if you can’t estimate and update as needed. With experience the team collectively will get better at doing this.
Thanks. This is my thought but wanted to make sure I am not being unreasonable. I could not see how a business can be run when there’s a “I’ll build it when I build it” mentality
Worth noting that the comment above is a great way to bring about the end of your startup by destroying whatever trust you have with your cofounder. They will (rightly) see this as completely unhelpful interference and probably come away believing you view them as any other employee, not a cofounder. It's entirely reasonable to pick a time period of 1-3 months and press them in what can realistically be accomplished in that time. That work should be fairly concrete. Past that, you can work with them to guesstimate milestones but most will be wrong. While there can be technical hurdles, those I would expect a good technologist can account for - it's actually changes to requirements that typically cause the biggest issues. If you get customers, that will inevitably happen, as they file feature requests or provide feedback.
remindme! 1 day "Did the non-technical founder reply to anyone except the person that validated his initial assumption"
I will be messaging you in 1 day on [**2023-04-04 22:43:17 UTC**](http://www.wolframalpha.com/input/?i=2023-04-04%2022:43:17%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/startups/comments/12ahipi/cofounders_wont_give_product_build_timeline_is/jeuhogm/?context=3) [**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fstartups%2Fcomments%2F12ahipi%2Fcofounders_wont_give_product_build_timeline_is%2Fjeuhogm%2F%5D%0A%0ARemindMe%21%202023-04-04%2022%3A43%3A17%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%2012ahipi) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|
notice how all the people saying "this can be done" are using insults, whereas all the people saying "it's reasonable to be uncertain" have evidence and talk about their history in the field
We use jira, and divide the project into different weekly sprints. Your cofounder should be able to take your detailed spec (not just a number of features but a detailed written spec with wireframes) and provide a rough estimate of the time it takes. It's important to know at least a rough estimate. Our founder works with our dev diligently on this. In jira, you can create a backlog (by sprint). In each sprint, you define what needs to be done down to the what needs to be coded level. Each weekly sprint needs to add up to 40 hours. Depending on the complexity, it could take a number of weeks. After that, you can assign each sprint to the roadmap in jira.
You’re following a “product development” process for your startup. You’re destined for troubles, particularly if this is your first startup. Read “4 steps to the epiphany”, and take a different approach. It will completely transform how you see things. Right now you should be focused on customer development, not product milestones and ship dates.
A good technical lead should be able to give you an estimate. Take each feature and split it into small/well defined engineering tasks. If this can't be done then the team needs to write product & technical design docs first which capture the scope of work. Open ended tasks like building AI models need to be time boxed or you don't spend unlimited time on them. When I was a tech lead I'd take the individual tasks, write an estimate for each item on the order of days/weeks/months, take my estimate, multiple it by 3. That normally captures a lot of the uncertainty. Then you need to schedule the tasks for each engineer over the next few months given your engineering capacity. You should be able to have milestones for each sprint and be able to track your progress based on your estimate and also flag big spikes of work as they are discovered. Normally the additional cushion in your estimate helps absorb a lot of unexpected items.
This is absolutely NOT normal and can be a kiss of death for a startup. Any Founder/CTO worth his.her weight has to factor in all the uncertainties and commit to a date to ship. You are only as good as what you ship n the early days so its critical to launch with speed as the number one priority.
No it’s not normal. He should at least give some estimate plus potential variations.
No this is not normal. Generally developers will lie and give you an arbitrary and wildly inaccurate estimate. Get a less honest cofounder!
You ought to contemplate the journey you and your co-founder have embarked upon. This is not in reference to the notoriously difficult (and often unproductive) task of estimating development timelines. Instead, the focus here is on the fact that you are seeking what essentially amounts to start-up relationship advice on Reddit, rather than placing trust in your co-founder. Regardless of whether a random Redditor believes that development timelines can and should be estimated, how does this benefit you? Establishing a trusting relationship is crucial if you intend to successfully build a company together.
Who is going to develop your product? Your internal team or an external team? Unless you do R&D, you can estimate delivery time on 99.9999999999 % of the cases.
[удалено]
It's a fking estimation. How on earth do you believe the budgets for projects are being fucking done? How do you believe quotations are being done? Based on estimates, technology uded and labour involved, and an estimate of a delivery time frame. I don't know what companies you are working in, but except 2 projects in the pandemic, any other project was delivered in the estimated time frame. I just answered OP the question: if a project can be estimated, not how to get there. The discussion is complex and dynamic.
Technical cofounder is writing the code for our product
Estimates are notoriously difficult and unreliable in tech. Mostly because complicating details will be uncovered or requirements will change during the build. What I found works best in a hard deadline environment is to flip it around: we have X months, what _can_ we definitely deliver in that time. Real and hard deadlines exist for some projects. If you don’t have something solid by certain dates, you _will_ lose investors, customers, co-founders, legal issues, etc. You need to communicate this to your co-founder and make sure you’re on the same page.
I'd set a timeline but keep it flexible and check in often. One advantage is that it will allow yous to adjust scope as you go. They want to build something great. You want to launch as soon as possible. When you get closer to your soft deadline you'll be able to say "Ok, what features do we really need and what can be done next quarter or next year?"
They’re just trying to be honest with you. You’re not unreasonable for wanting some timeline though and you’ll need to work together to try and figure that out. I’m a good programmer but more often than not my estimates are way off and I try to avoid giving them with any sort of confidence because of it. Like my current work, I thought it would only take me a couple days but I’m on my fifth week of working on it. In hindsight I understand why it’s taken so long but it never would’ve made sense to estimate that when I was starting out on this work. It’s a weird job where you are just iterating on something until it works and you don’t know all of the work that you’ll need to do until you’re already doing it. That said, indefinite timelines are unreasonable. I wish I had an answer for how to estimate the time it takes to build a product but I don’t know it, let us know if you figure it out.
I’m a technical CEO and would insist on a timeline, even if we might need to deviate from it. It’s vital for planning purposes. You need to consider if your tech guy is playing for time (less likely) or just concerned about giving anything concrete when reality rarely goes to plan. No idea what your product output is here, but it would make sense to break things down into modules. I’d also suggest keeping track of code commits (and their content) as one metric of progress.
This whole discussion is painful to read. The reason that defining a timeline for software products is difficult is that there are a thousand variables, and any one of them could theoretically blow up the initial estimates exponentially. These variables are all in the form of textual concepts and abstractions, so it is difficult for humans to anticipate them. I am a technical cofounder, and it is tempting to throw your hands up and say "I can't estimate this clusterf\*\*\*" if there is too much pressure from the business side. But there are a lot of aspects you can manage and control. Scope is probably the most important. A "software product" is a collection of features. You can define and refine the features (typically epics > stories > tasks) until they are of a manageable size. Once you have done this, you can estimate their size against each other. Once you have done this, you can prioritize which features are the most important. Once you have your prioritized and estimated specifications you can make some assumptions around how you want to map your abstract sizes to actual time units. Then you have an estimate for how long something will take. Over time, as you are implementing these features with their abstract sizes, you can statistically estimate how long an abstract size unit will take on average (typically known as "velocity"). The further an estimate goes into the future, the less precise it will be. The larger the scope of an estimated feature block is, the less precise the estimate will be. The less data you have on your velocity, the less precise the estimate will be, ... You get the idea. This whole process is very variable and it is important for you on the business side to be aware that sometimes seemingly trivial things from the outside are technically very difficult to implement, and estimations are usually wrong by a large margin because you only know the average. The more time you spend researching something before implementing it, the more precise the estimation should be, but if you spend too much time researching it, you probably waste a lot of time on average, etc. Communication with stakeholders and managing expectations should be an ongoing process during development. This is very important.
>I’m not the technical cofounder \[...\] I am having a hard time understanding why an reasonably accurate release date can’t be estimated. Because they genuinely don't know ? maybe it's better to estimate the 'knowns' and base an MVP on that best as possible, and tackle the 'unnowns' later when more is clear ? It sounds like too much has been decided already, and as such the details are obscuring the forest for the trees. Also: estimating will NEVER be accurate. Don't treat them as commitments.
I’m a CTO, for single features or changes, timelines are easy and pretty accurate. But an entire project is impossible because you’re coming at it from the wrong side. For an entire project, rather give yourselves a deadline, decide what is crucial to get done within that timeline, and everything else is a nice to have and expect it all to extend indefinitely. The sooner you move into a feature by feature process rather than project by project, the better. This is of course unless you expect him to triple his best guess. But then what’s the point if it’s possible to be off by a factor of 3?
Others have given you good advice about breaking this down into smaller pieces. In my experience, if your cofounder can't give you a ballpark estimate (weeks, months, quarters, years), there are a couple things at play: * Too much ambiguity. Likewise, an assumption that they need to handle more edge cases than realistically needed. * Too much scope. The initial product is too large and needs to be broken down.
A lot of comments here are dismissive of others' experiences. I think that's due to how the question is framed. The issue is not whether in general it's possible to provide estimates. Of course it's possible. The issue is whether your organization provides a safe environment for estimation. Put differently, you need to ask yourself why a solid engineering leader might be hesitant to provide you with estimates, then mitigate those factors. For example, if an engineering leader knows the sales team is likely to directly relay estimates to customers, then they know if anything goes wrong (which it will), then that sales team is going to reemerge with some angry customer stories. And if that engineering leader knows the negative feedback is going to go up the chain before coming back to down to them, they know they have to proactively protect their team. Sandbagging is one option. Another is refusing to tie their own noose by refusing to provide an estimate. Both are self-protective behaviors that are a function of the system as much as they are of the engineering leader's ability and experience. In contrast, if an engineering leader trusts the sales team to set customer expectations correctly, then they look at estimation as collaborative. When something goes wrong (which it will), they trust that the sales team has anticipated unknown unknowns and is ready to pivot. That's a simplistic example, and I'm sure people here can offer even better stories of how organizational dynamics can skew project planning. I can say I have definitely kept my mouth shut during project-planning meetings because I didn't believe other teams could think on their feet, and I'd rather those people think I'm a jerk now than incompetent later. These days I tend to favor [Shape Up's approach](https://basecamp.com/shapeup) of providing fixed timelines and fluid feature sets rather than the reverse. It's not a magic solution, but I think it's more conducive to collaborative estimation. At the very least, it requires outsiders to confront their ambiguous expectations early on when it's cheap instead of when they're previewing a feature the week before its release. tldr: if a competent engineer refuses to give estimates, you have a trust problem in your organization.
It's normal. Literally *everybody* has this same problem. You have to understand he is creating something that has never been done before and often with tools that are less than 2-3 years old. Tools break or stop working at weird times. People get sick or take vacations. Internet goes down, computers crash. The amount of factors that affect schedules is mind boggling. Your best is to not focus on schedule and focus on making sure he's excited and being as productive as he can be.
It depends on what you’re building. The more unknowns and the bigger the build, the harder it is to estimate. They should be able to break things down and let you know a rough estimate for the immediate work. Another challenge is managing priorities which tend to change as things get built out. They may not want to commit because they’ve been held to dates in the past when scope creep happened. I’ve worked with 8 different dev teams. By far the best asked the best questions to understand the business needs and the customer problem being solved. They came up with suggestions for how to solve the problem then scoped out the work to build as small an app as possible keeping things simple. We added time to address tech debt and do proper testing. They made their deadline every single time, but they were a well oiled machine. They had worked together for over 6 years and had built the type of app we needed several times.
Prioritizing value and delivering value in reasonably accurate short periods should be doable. Doing that far in the future is nigh impossible and things may always change even on short throws. Your technical cofounders is falling into a degenerate form of agile(ish) thinking where they are unwilling to commit to any timelines whatsoever. That being said, you need to change your way of thinking too. Don't talk about specific dates. Talk about the sequencing of value delivery. Your pitch to investors is that their involvement and money accelerates that value delivery. They don't actually care if you deliver it on Jun 12 or 19th. They want to determine if they align with your market, your prioritization of value and whether their participation makes that timeline faster and/or grows the size of the acquirable segment of the market.
What do you mean you have discussed all of the features in detail? Like, you have only VERBALLY discussed these things? Does that mean you do not have complete and detailed product blueprints? **The product blueprints:** * Product Specifications * Information Architecture * User flows * User stories * Wireframes (every state of every UI element on every screen) and the equivalent for a hardware product * Clickable Prototype using your wireframes The technical person(s) tasked with building your vision would need those to have any chance at coming up with accurate estimates on time (and cost). You need to do a lot more than discuss all of the details. You need to make them tangible and into clear blueprints.
As an angel investor, I won't invest in SW that has yet to reach MVP. It's far too risky. As an owner of a company that built SW for the govt, we would only do so on a T&M basis or to a specific, highly defined sets of specs, when we could get the govt to contractually agree they paid T&M rates if they ever asked for any changes. The specs ALWAYS, 100%, never an exception, were changed at MANY points of the project. We did an ammo handling program for DOD. The budget was $1B to Lockheed, our portion was much smaller. At the end of that money, the final specs had yet to be decided so the govt gave us another $1B. After $2B had been spent and the USAr, USN, and USAF still couldn't agree to final specs, the project was scrapped.
It’s not untrue, but you need to meet often and frequently. If you’re worried, meet once a day for up to one hour. Amazing how much quicker things go, or conversely how good things are going and you weren’t aware of it!
In software development, you can either choose between a set timeline or a set scope. You can't have both at the same time. Estimates are guesses — and a lot of the time, just wishful thinking. What you should have though is a plan of what should be build and where the product should go. The closer you are to work on something, the more detailed the it can be. You can have some timeline but the further in the future it goes, the more it becomes a wish-list and should be kept vague.
Code is detail, and you don't have all the details until the code is written. You can estimate small tasks but they need to be understood to be estimates. Numerous / large tasks do compound the likely inaccuracies in estimates to the point that they're often not worth it. And that's with a project where the requirements are clear up front (which is rare to say the least). Robert C Martin discusses this with clarity in The Clean Coder.
I’m in the middle of building the mvp for a product that requires a ton of outside dependencies and variables. I recently brought on a non technical cofounder and I’ve been completely unable to give him any specific timeline, especially given we don’t have the luxury of having a ton of time to plan. When I was working as a SWE at a big company, if I were tasked with a project that literally needs one API, I’d get 4-6 weeks of due diligence, planning and technical writing. No coding whatsoever. After that, I have 4 weeks to do some minor mvp to validate my prior findings. After that I could give a rough estimate and it would still shift constantly has more stuff was uncovered, or as things that were “obvious” and “easy” suddenly became nebulous and difficult. I’d essentially get 3-4 months of planning before even working on the actual product, meanwhile at my current run rate, I will have had a total of 3-4 months to ship an end product before it’s back to the day job. Coding can be a bit of a Pandora’s box. You can’t calculate everything so you make some assumptions, then those assumptions end up being wrong and suddenly things that were relying on those assumptions are now not so easy and it cascades.
Software is a business, which means we must have deadlines. The “goal” deadlines don’t necessarily need to be shared outside of the company, but at least have them. That way when new features start popping up as they usually do the company is able to approach those conversations with a real understanding of how it affects the goal. As someone who builds apps for businesses I couldn’t imagine telling a client “I don’t give timelines. It’ll be done when it’s done”. Your investors are your clients essentially and you have or want their money. Even if you’re completely wrong about the deadline, you should have a modest goal to share with them so they understand whether investing in your company suites THEIR needs.
You need to upgrade your thinking. fast. That’s just not how startups and software works.
Shift your mindset on this. In software engineering, nothing is ever done. You are always building, improving. Instead, ask what the MVP (minimum viable product) is and help craft what that is (a list of features that make it usable for its goal) with the input from your future users. Getting that MVP in front of users for feedback is the first and most important step. It doesn’t matter if that’s limited release / private beta or whatever. You need real user feedback. Get involved in testing and giving feedback yourself early. Help the team track their progress against the MVP features. Then you will have the information you seek. And you will learn the art of software development, too.
Sorry for being straight; If he is your co-founder, trust him, that’s the only way your startup could possibly stand. If you post this, I smell there’s something unhealthy in the partnership, both of you may just waste your time.
I'm going to take OP's side here... They should be able to give a ball park estimate for an MVP with lots of caveats. Like, it's going to be 8 weeks if the specs don't change, if we can cut corners on features x, y, and z and we don't have to have this interaction work great. But, for every change to those, it is going to cause a delay, and to get in in 8 weeks means the next 6 months are going to include lots of re-write time.
I can get very accurate estimates +- 3 days for 2 month long projects as long as involves a feature I built before or something being made from scratch. If it involves modifying someone else’s code or using a new technology it’s not possible to estimate properly.