3 ms·
Don't charge for your time if you can negotiate a better arrangement. Instead attach prices to specific deliverables. Ideally the prices have some relationship
by gregjor 3y ago
Don't charge for your time if you can negotiate a better arrangement. Instead attach prices to specific deliverables. Ideally the prices have some relationship to the business value.
You should focus on adding business value and how to attach fair prices for delivering that value, in concrete terms. Hours spent at a keyboard, or lines of code, do not describe anything of value to a business.
You can ask the customer to attach a value to deliverables and then decide if you can profitably deliver. Structuring projects to support that means you and the customer have to break the tasks down into well-defined steps with clear deliverables, something freelancers should do in any case. It also means getting the customer to think about business value. You should also consider cost over time (i.e. is the customer losing money because of a bug or missing requirement), and risk to the business.
Freelancers too often either accept a price the customer attaches to a project (based on what?), or guess at the time required and multiply by the desired rate. No one specifies the project in detailed steps with clear deliverables and a definition of "done" for each stage. As a result the freelancer and the customer will conflict over schedule and budget, usually well into the project.
For skilled freelancers with a solid reputations "a few hundred of dollars per hour" doesn't describe a "crazy rate."
- badpun 3y ago> Don't charge for your time if you can negotiate a better arrangement. Charging for time makes perfect sense in some cases, though. If you're working for a pointless startup that is likely never going to be profitable (or "exit" while unprofitable), you can't express your rate in terms of business value because, well, there isn't any.
- gregjor 3y agoYes, sometimes you sell your expertise and experience, with vague goals, or no goals, and no defined deliverables. I call that consulting, and would negotiate a retainer rather than hourly billing. But sometimes you have to go with hourly. Some customers don't have the internal organization or focus to work out anything better than that. Because it comes up with startups specifically, I wouldn't accept equity in lieu of pay. If you strongly believe in the startup and the possibility of success, that might make sense, but as a gamble rather than a predictable income.
- xp84 3y agoI mean, you may think rightly that there’s no business value but it is the customer’s estimate of business value you care about, not yours, because you want to gauge what it is in order to estimate how big a fraction of that number you can extract as your share. You’ll get paid long, long before they fail, sell, or IPO!
- lylejantzi3rd 3y ago> Freelancers too often either accept a price the customer attaches to a project (based on what?) > You should focus on adding business value and how to attach fair prices for delivering that value, in concrete terms. Based on what? I'm not a business analyst. I have no idea how much business value a particular project could be worth to my client.
- gregjor 3y agoYou talk to the customer. If the customer doesn't have a budget or a price range based on value to the business, red flag. The customer should have some idea what they expect to make (additional revenue) or lose (costs or risk) before they start asking for bids or looking for a freelancer. I just ask, "What is this worth to your business?" or "How much is this bug/missing feature costing you?" If they don't know or won't say I probably don't want the gig. Sometimes the customer needs help identifying the business value, costs, and risks. A successful freelancer has to do some analysis, business and technical. Otherwise they are just selling their time for money as a temporary employee.
- mettamage 3y agoI wish there was a small course on this on how to navigate this.
- gregjor 3y agoYou need domain expertise to do useful business analysis. Sometimes the customer can explain their business in sufficient detail, sometimes they can't, or the business domain is sufficiently complicated that you can't just pick it up. I don't know any good way to get domain expertise other than on the job. One thing you can do in a programming role is to take an active interest in how the business works. Talk to people in other departments, ask questions. Early in my career I had to "cross training," which meant shadowing or even actually doing other jobs so I could see how the business works. I not only write code, I can operate a fork lift, thanks to cross training.