Engineers hate sloppy code. It’s hard to understand, harder to change, and even harder to scale.
But show me an organization that doesn’t have a gnarly code base. At Google, where engineers are brilliant and know how to write good code, it still takes them something like six months to get comfortable making even simple changes.
And that’s a problem. Because arguably, from Day 1, code
quality is right up there with serving the right product to your customers.
This is because the engineers who contribute to the code base are the customers of the code base. And unless someone is trying to hear and address their needs, there are a few ramifications:
The highest stakes? Recruitment and retention.
People get really frustrated having to contribute to something that’s hard to work with. If it takes ten hours to get Feature X into one code base when it could take an hour somewhere else, that’s not great for morale.
So how do we prevent this?
Ideally, you have someone keeping your code in good shape the moment you start writing it.
Because it gets exponentially harder as an organization grows.
Now, let’s say you have 30 engineers in your organization. Ideally, you’d have a couple of cross-functional team members, with background in all elements of coding your products touch – whether that’s frontend, backend, mobile, iOS, etc. These are folks that are willing to take on the more thorny issues. Make taming the code base their sole purpose, and you’ll avoid a lot of code rot.
“But I don’t have the funds to clean up the code base. I need to ship features to my customers!”
You don’t need to address all the issue immediately, but you need to have a plan in place. You may not have a shovel, but you need a spoon. You have to make forward, incremental progress, otherwise the time and energy it takes to add even simple features to the code base will grind to a halt.
So yes – it may seem like you’re shipping some features later than you wanted do. But if your developers quit, we promise that’ll delay your roadmap a whole lot more.
How should code base NPS be measured?
While a pure Net Promoter Score (NPS) is useful here (i.e. “Would you recommend this code base to a prospective employee?”), we think companies should use a couple of others to triangulate:
How long does it take for a new employee to get up to speed? In our opinion, this shouldn’t exceed 2-4 weeks – though this obviously changes based on logic and components. But pick a number – because ideally, it should never change. If it does, that’s a sign you need some cleanup.
How comfortable are engineers making changes after X number of days on the job? This should generally reflect your NPS score.
Imagine: You’re new to a job and the code base has architectural changes that are alien to you, because you’ve never made those changes in his work. And deployment in particular is a huge hole – and there’s fear behind it. Fear that your peers will break the website if they deploy.
This is terrible for morale – and not great for productivity either. Engineers are at their best when they have the freedom and creativity to solve problems, and a complex, restrictive code base doesn’t allow for that.
With a solid code base, anyone should be able to kick off a deployment. Whether it goes to production is another story, but it needs to be easy. The moment your developers are afraid of breaking the website, they start being less productive. They’ll be thinking about whether a seemingly benign change will break the website – is what I’m doing safe? These should be two separate questions.
So how can larger organizations improve their code base NPS?
It depends who you are. If you’re the CEO or CTO, you either need to take the lead, or pick someone from your organization who will be your right hand person in implementing a code base”tiger team”.
The first thing to do is establish guidelines for what’s acceptable.
What metrics will you use to measure on-boarding?
How will you measure ongoing code base satisfaction? (which, btw, is a really good predictor of employee satisfaction)
Once you have the metrics in place, build your team – and this will depends on the size of the organization. With 500 engineers, 1 person won’t cut it. So pick up a team from different parts of the org, and make sure the code base is super usable based on those NPS metrics.
Remember, your code base is the product you’re building for your engineers & future engineers. It needs to be something they feel happy working with.
Most engineers focus on HOW to do something – not whether they SHOULD.
Engineers tend to be very intellectual – curious about how to solve problems, because that’s fun. But asking whether a problem should be solved is something everyone should be doing, at every level of an organization.
Dan recently started working for a great mid-sized startup (a departure from many years of ideating & building MVPs. During his interview, he was given a coding task – and part of the ask just didn’t make sense from a product perspective. He didn’t see how adding this feature would benefit the customer & the business, so he didn’t do it.
When Dan explained this to his interviewers, they were surprised – apparently no one had ever done this before. But they loved it. Because all organizations need contributors who can improve the bottom line of the business, not just execute a development task.
The Cost of HOW
The challenge here is that most organizations aren’t structured to empower engineers to make product decisions. And a result, it’s a skill that many engineers never cultivate.
And this makes sense – there’s a lot of value in splitting out functions and teams as businesses start to grow. But when your engineers are disconnected from the customer, the market, and why the product exists to serve them, there’s a cost, from…
Wasted development dollars, to
Lower employee morale (and potential burnout), to
A “kitchen sink” product – rather than a lean machine focused on customer needs
Don’t get me wrong – having engineers who understand how to do something is critical. But HOW is only valuable after you’ve decided the SHOULD.
In fact, sometimes the best solution is one where you have to write no code at all – and that saves time and money.
But this runs counter to a lot of today’s work culture. We equate seeming “busy” with contributing value – and as a result, we’ve trained our engineers to do those tasks in JIRA, simply because checking them off shows their managers that they’re productive.
And when those tasks include features that aren’t really impactful? This has huge implications for employee morale because no one wants to work on something that no one will ever use.
Creating a SHOULD Culture
In a perfect environment, everyone is comfortable saying NO. The default is, we don’t work on something unless a customer really needs it. Because too often, the impulse is “this is exciting, let’s build it”.
Now, let’s say you do have an engineer (or you are an engineer) who IS thinking about whether something should be done. If that engineer isn’t involved with the product process until the development stage, saying NO threatens egos upstream – because people have spent a lot of time and energy up until that point.
In order to make this a part of your culture, you have to involve engineers at the beginning of the product ideation process. This has 2 key benefits:
Engineers are deeply connected to the customer, their needs, and WHY a product is being built – so they CAN say no later on, with good reasons for doing so.
Product / business stakeholders get early technical feedback, which can totally change how they approach requirements.
In practice, you’d have at least 1 engineer who will be working on features involved in product discussions from day 1 – from inception, to execution. So in theory, by the time a product brief is delivered to your developers, SHOULD has already been addressed from their perspective.
So that’s a perfect world. But in the real world, where most organizations silo product decisions from development tasks…
How can engineers develop a SHOULD mindset?
Think critically about whether or not this thing you’ve been told to work on makes sense to you.
If it doesn’t make sense to you, then either it’s not being communicated well enough, or the inherent value isn’t obvious. And if the value isn’t obvious to YOU (who know your company and your product), it isn’t going to be obvious to someone who is a customer.
Now, if you don’t feel like you understand your customers’ needs, go find out. Product marketers can be a great place to start. Talking to customers can be even better.
Because if you don’t understand what pain points you’re trying to solve, and who you’re solving them for, a task will only ever be a task. Key into the why and the SHOULD, and suddenly your code feels like real, tangible impact.
If you’re a contractor working with startups, you can be a venture capitalist.
(pause for impact of sweeping statement…)
But seriously – as a freelancer, you’re in a unique position to be an investor, by virtue of your skillset and the types of clients you might choose to work with. This varies depending on your niche, and is particularly true if you work with greenfield apps, for startups – because you now have the ability to choose how you get paid by your clients.
How can freelancers become investors?
If you’re working as a freelance software developer for a corporation, you’re out of luck – cash payment is probably your only option.
But if you’re working with a startup, things can start to get interesting. And if you’re in a position to take some calculated risks, they can pay off really well.
You might be thinking, “But I can’t afford to invest right now – I’m just trying to pay my bills.” Here’s the thing: some of these models give you the flexibility to invest just a little bit of your time – and even that little bit can pay off A LOT in the end. So don’t write it off quite yet.
Heads up: There are 5 things you CANNOT forget to do if you go with any of the models below, so stay tuned for our post next week.
Model #1: Full Equity Compensation
When Dan started his first agency, he and his buddies took projects only for equity compensation. Basically, they would isolate a business problem, create the technical product, and recruit their friends (!) to quit their jobs and run the company for a set equity stake.
While handing off a business to your friends is a little atypical, it’s fairly common for early stage startups to pay contract developers in equity (because they don’t have a lot of cash).
There are some pretty obvious pros and cons to this approach:
Pro: 10 years later, we have investments in several companies that are still viable, and poised to make sizable exits at some point.
Con: Dan made no money for a year. This was frustrating (*ehem*). Make sure you have a spouse or partner who can bring home the bacon if you do this, or have a stockpile of savings to live off of. Also, these investments may or may not pay off, so this is a real leap of faith. You have to reallllly believe in the business and in the team.
The upside of full equity compensation is that you can typically get way more equity per unit of time than other options. You’ll probably end up with more equity in the projects you work on than FT employees and even later stage investors (especially if you’re coming into the project in its fledgling state).
How much equity should you ask for? Like I mentioned above, it really depends when you get involved. If you come up with the idea, recruit a friend to work on the business and then peace out, you’re in a position to get a fair amount (think ~5-15%). In other situations, you can probably swing anywhere from 1-5%.
Of course, it also depends on the scope of work involved for you, but any of these options provide a lot of equity for the time you invest.
Model #2: Convertible Equity / Safe / KISS
While full equity gives you insight into your piece of the pie right off the bat, sometimes it’s nice to know that your investment directly correlates with the amount of work you put in.
If that sounds appealing, you might want to consider accruing the time you work with a startup towards the value of a convertible note.
What it is
Basically, a convertible note is an agreement that gives you the right to acquire shares in an entity upon some “convertible” event.
Usually, this “event” is when the company sells shares of preferred stock in a priced round, but it can also manifest as a time-based conversion (see #4 below).
So why should you consider this (or not)?
Pro: Founders like convertible notes because they give them breathing room – which makes it easier for them to say “yes”. With a note, a startup doesn’t have to commit to a predefined/arbitrary valuation (in our experience, trying to agree on this can quickly derail a negotiation).
Pro: You, as the investor, have the flexibility to quantify what your services are worth, and assess whether you’re comfortable with the size of the investment you’re making at any point in the project. You’re being compensated for every hour you work, and there’s no binding agreement to complete an MVP. If you believe in the project, the equity you’ll get by working more is a great motivator. And if you aren’t feeling motivated, it’s time to either move on or re-negotiate.
Con: Because you don’t know what the valuation of the company will be when they fundraise, you can’t calculate what your equity stake will be. It could end up being 0.25% or 5% — there’s just no way to know. But it’s also a little subjective at this early stage, because if you pick the next Google, you’re going to make out like a bandit no matter what.
If you’re working with family or friends, notes are a great option.
They can be great motivators in situations where you aren’t comfortable with money changing hands (e.g. you’re doing an act of service for a friend, but they want to make you feel valued for your time). We did this recently with my cousin, Abby, to help her launch her NYC-based jewelry company, EACH Jewels.
How it works
When we structure a convertible note, we typically inflate our hourly rate to account for the risk we take here (because there’s always a chance we won’t see a return on our investment).
So if we typically charge $100 / hour, we’d charge at least $200 / hour to accrue towards a convertible note.
Practically speaking, if we work 200 hours on product, we’ll get a $40,000 note in compensation. If a “convertible event” (e.g. funding round) takes place, that note then converts into >=$40k of equity (the exact value will depend on the discount rate, which depends on the terms of the round).
There are lots of “open source” convertible note versions floating around the Internet, but we recommend Y Combinator’ssafe (simple agreement for future equity) if the company you’re investing in doesn’t already have a prepared version from their legal counsel. We also recommend you work with Clerky to write up the paperwork if you don’t already have a copy reviewed by a lawyer.
500 Startups also has their own version of a convertible note, which they call a KISS (“Keep It Simple Security”). If you decide to use it, we recommend you use the equity version (again, we’ll get the “why” of this later).
As mentioned before, a big catch with notes is that they may never convert. In this case, note holders are usually the first to be repaid. YC explains this in their SAFE Primer:
What happens to a safe if the company shuts down and goes out of business?
In a dissolution, any money that the company has to distribute would be distributed to safe holders before any money is allocated to holders of common stock.
So while convertible notes are still an investment, the risk is mitigated a bit more than with pure equity compensation.
If you like the idea of getting a little more ROI for your time, but using notes by themselves feels too risky, check out Model #3.
Model #3: Convertible Equity with Cash Cap
You want to invest in a company you’re working with, but you also have bills to pay.
One solution to this that we’ve used with great success is to give founders the option of capping their cash investment at a certain threshold (e.g., $50,000), and then applying accrued hours over that threshold towards a convertible note.
Pro: This model incentivizes everyone involved.
You, the programmer, know that you’ll get paid a predictable amount of cash for the work you’ll do up front. And once you pass that cap, you’ll reap all the benefits of a convertible note (with a team you know is reliable since they’ve already paid you cash).
For the founders, they get line of sight into their budget for the first round of development and can plan accordingly. And after that point, they’re assured that you’re now a stakeholder and essentially part of the team.
Con: Same as a general convertible note, but mitigated by the up-front cash payment. You’ll likely end up with less equity though, since part of your payment is in cash.
Model #4: Convertible Debt (i.e., convertible note with time-based conversion)
This is similar to models 2 and 3, with one important difference. If the startup doesn’t receive funding or get purchased within a certain timeframe, they are legally bound to pay you in cash, at your standard hourly rate (or whatever you negotiate).
Pro: You have some degree of protection if the startup never raises a round of funding — it’s theoretically the best of both worlds (security of cash, potential upside of a convertible note).
Con: If they don’t raise a round, you don’t reallly have a guarantee that they’ll pay you. If they’re depending on raising that round to stay in business, they may not make it. This, of course, is a risk any time you work with a startup, so if you’re comfortable taking them as a client in the first place, this shouldn’t be too much of a concern
Note from Dan: We don’t recommend this arrangement, and here’s why:
Let’s examine two scenarios:
On one hand, let’s say the company you’ve invested in is blowing up. They’ve hit product-market fit and they’re making so much money that their bank is blocking their check deposits. In this case, you’ll get your money back, sure, but at the expense of a chance to make an incredible investment.
That’s pretty silly. You might as well have just taken the cash from the get-go.
On the other hand, the company you invested in is currently struggling, and can barely pay its existing bills. In this case, they just don’t have the money to pay you back, so your agreement won’t mean much anyways.
Ticking time bombs like debt repayment can also be a large source of stress for founders. Startups are stressful enough as-is. </dan>
What does a revenue sharing agreement entail? Well, in our case, we were guaranteed to receive 100% of all revenue, up to a certain dollar threshold (let’s say $10,000), and a percentage of all revenue after that (let’s say 10%).
But they did want a partner who had “skin in the game”, and would be invested in their success, long-term. So instead of an equity model, we created a revenue-sharing agreement specifically for the apps.
So if the line of business brought in $20,000 of revenue in a given month, we’d make $12,000 (first $10,000, plus 10% of the subsequent $10,000).
Here’s a quick summary:
Pro: By guaranteeing a certain chunk of revenue, we had assurance that we’d be paid for our work (given the other party did their part 😉 ).
Pro: By giving us a percentage of all revenues after that threshold, our partners kept us motivated to give the product our all, since the sky was the limit on how much we could ultimately make.
Con: As with any equity agreement, there’s an element of trust here. If your partner doesn’t hold up their end of the bargain (e.g. sales), you may not make very much at all.
Con: There can be a pretty significant up-front investment of time to get the product off the ground. This model is not one that allows for much flexibility in terms of the time you’ll need to put in – it’s basically all or nothing (though there’s room to negotiate on how you get paid).
The beauty of working on new projects is that you have a lot of flexibility to design the compensation that works for you. And, in the case of startups (and a lot of small businesses), alternative models for compensation are really attractive because they want flexibility too.
The 5 examples above are all models we’ve used successfully. You can pick and choose pieces of each to create something that works for you. I’m sure there are more creative strategies that would work great. It’s just that no one has thought of them yet.
One recommendation: Find a lawyer who specializes in contracts for startups, and have them review whatever you sign. There are a LOT of nuances when it comes to equity and partner agreements, and you want that you’re protected. (Obligatory disclaimer: Please consult an attorney if you’re going to pursue an equity arrangement. The App Hacker does not assume any responsibility for any consequence of using any document mentioned in this article.)
Note: if you’re going to take equity in a startup, there are 5 things you should know about alternative compensation (on the blog next week).
So sign up for our email list, and stay tuned. 🙂
Have you tried any of these approaches to compensation as a freelancer or agency? Tell us about your experience! What worked / didn’t work? Comment below or email me at firstname.lastname@example.org.
This week, Dan and I sat down and talked about what went well in 2018, and what was challenging.
We call this our “Year-End Planning” meeting, and do it every December to align on our priorities and goals for the year ahead. We talk about Lionheart Software (our consulting & app business), new ventures / partnerships, and our family.
Well, except for last December. And that was a BIG mistake (or the best thing ever, given what we learned from it).
Usually, our year-end planning gives us a set of guidelines we can use to make decisions in the new year.
There are two components to this: 1) Priorities, and 2) Goals (TLDR: scroll down to the bottom for how-to’s).
This is particularly important for us since we’re partners in business and life. As entrepreneurs, it can be hard to set boundaries – and since we don’t see divorce in our future, we need to be on the same page to make trade-offs between relationships, health and work.
But last December, our whole family got the flu. And by the time we recovered, we were back in the swing of work and just couldn’t seem to fit in our planning session.
Lack of planning yields mixed results, and a lot of wasted energy.
In a nutshell, 2018 was rather stressful, despite ending on a high note. And the happy ending was primarily because we finally did our planning session in Q3. But we learned a lot, and will definitely be handling 2019 differently as a result.
So, without further ado…
Q1: Built new tools, interviewed with Y Combinator, but missed the mark with income.
While we had talked about our financial goals for the year at a high-level, Dan and I never aligned on how we’d balance internal projects with billable work for clients. So without much forethought, we spent the bulk of Q1 building a tool called Nucleus to automate dev-ops and infrastructure.
Initially, the tool was designed for 100% internal use, but we decided to apply to Y Combinator on a whim and actually got an interview.
It ended up not being the right fit for us, which we should have known from the get-go (and would have, had we planned appropriately – our goal has never been to grow a $1B company). And while we grew a lot as business-people just by going through the process, by the time we figured that out, it was April.
The positive? We now have a rockin’ tool that saves us 10-15 hours of work on every project.
The negative? We spent A LOT of time on a venture that we decided not to pursue – and got behind in our client work as a result.
Q2: Severe burnout + heavy client workload = mental health challenges.
Not surprisingly, Q2 was a tough one.
We had already worked our butts off to get Nucleus to a point of usability, and now we had to put pedal to the medal to ship a few products for clients (because paying bills? Unfortunately not optional :().
It didn’t take Dan long to get majorly burnt out, and he had a pretty severe brush with depression / adrenal burnout. It’s something most entrepreneurs (and a lot of developers) are familiar with, and while it’s being talked about a lot these days, it really snuck up on us.
Normally, when we plan out our year, we try to build in some balance – and that’s something we really didn’t address well in early 2018.
Q3: More balance, but still some clean-up.
Thankfully, by Q3 we were doing much better, but we still had to wrap up some client projects from earlier in the year.
The upside of our mental health scare? We were forced to re-evaluate the way we want to generate income.
We’ve done really well consulting over the past 10 years, and there are a lot of things we love about it: direct ROI for the time we put in, the freedom to work on a lot of interesting projects, and the ability to really specialize in our niche.
The downside? Consulting doesn’t generate passive income (which is exactly what you need when you need to take time for your health).
So when we finally did our 2018 planning meeting (yes, in Q3), we decided that we’d start shifting our focus to some of our other ventures.
Q4: Kicked off 2 new partnerships, secured new business for 2019.
I think the most surprising part of this year was how quickly we righted the ship once we took just 2 hours to re-focus.
We decided that our priorities for the remainder of 2018 would be: Health, Starting new ventures / partnerships, and shipping 1 new SaaS or app.
And within a month, we had laid the groundwork for 2 new partnerships, plus a large client project for 2019.
Net-net for 2018: Late planning is better than no planning.
All in all, we’re excited about how we’re heading in 2019. We’ll talk more about our new ventures next year (one is a revenue-share partnership, and the other is a joint venture into the SaaS space).
Because this time, we have a new set of clear priorities and goals.
Now, if you want to try some year-end planning for yourself, it’s pretty simple…
How to do Year-End Planning
1) Understand your priorities before you establish any goals.
Over the years, we’ve seen that unless we lay out our priorities at a high level, it’s really hard to come up with actionable goals. By laying out your priorities first, you can create smart goals without over-burdening yourself (because the reality is, you just can’t do everything).
So what counts as a priority?
We think of priorities as spheres of influence, or broad parts of our lives that don’t necessarily overlap.
And the magic number is….3.
In our experience as parents, we’ve seen that at any given time, we can have about 3 of the following: A relationship with your spouse, Sleep, Time with your kids, A successful career, and Health / Fitness. Try to prioritize any more than that, and they’ll all suffer a bit.
To pick our top 3 priorities, we have to ask ourselves: What’s important to us this year?
Is it bringing our fitness to a new level? Is it building passive income? Is it taking a more active role in our son’s extra curricular activities?
Now, prioritizing doesn’t mean that you get to ignore the rest of your life. It might just mean that you establish fewer goals, or less ambitious goals within that sphere.
2) Set realistic (but ambitious) goals.
Once we know our priorities, we like to come up with 3-5 goals for each sphere of our life.
Goals should be ambitious, but attainable. You don’t want to set a goal for yourself that you have no hope of hitting. It’s better to exceed your goals and celebrate at the end of the year!
They should also be measurable (so think about incorporating something tangible, like numbers).
It might look something like this:
Grow passive income from internal apps to $5k / month.
Start one new venture / partnership that will be revenue-positive by EOY.
Automate our accounting processes (aim to save 10 hours of time).
Transition from consulting to recurring revenue from products within 2 years (need to be 25% of the way there by EOY).
Have one date night / month.
Go to one mommy / daddy & me activity / week.
Take one family trip this year.
Spend more time outside – aim for 1 family hike / 2 weeks.
Dan: Train for Austin half-marathon in February.
Rachel: Meditate daily.
Dan: Improve guitar skills to play favorite Metallica songs.
Rachel: Learn how to ferment so we don’t have to buy sauerkraut anymore.
Note that the business goals are pretty ambitious, followed by health – family and self-improvement are a little more low-key. We’re not ignoring our family or selves by any means, but this isn’t the year for Dan to do 8 triathlons (that was 2016), or for me to take time off to have another baby.
3) Figure out blockers & life hacks to make it all happen.
Now, it’s great to set all these ambitious goals for yourself – but what if you don’t have the means to make them happen yet?
Dan and I almost always have to put new support systems into place in order to hit our goals at the start of the year.
For example, if we want to have a date night once a month, I’d better make sure we have enough babysitters on rotation.
If we want to start a new partnership, we need to set some goals around number of new contacts we need to make in order to meet that person or company.
If it’s looking like our workload is going to be too much for the two of us, we’ll talk about whether we need to outsource or automate something.
And the priorities might cross-over as well. If we know we’re going to have a lot of billable work in Q1, I might arrange for a babysitter on the weekends to give us some more working time.
Remember, you don’t have to do it all alone – and often the cost of asking for / hiring help ends up being less than what it would cost you personally (not to mention opportunity cost).
Net-net: When you figure out your priorities and goals up front, it’s much easier to structure your life and business in a way that’ll help you achieve them.
What kinds of year-end planning have you done? What works / doesn’t work? We’d love to hear about how you hit your goals! You can email me at email@example.com.
Earlier this week, we talked about how to raise your rates as a freelance developer – and how to get your clients to say yes to those rates.
A key part of getting that “yes” is how you present your value as you negotiate. Over the years, we’ve found that focusing on what you bring to the table before you ever discuss price is the best way to sell a client – because by the time you do talk about rates, they’re already bought into your value.
But what happens if a potential client asks for your rate right off the bat?
We got a great follow-up comment / question from Russ (sidenote: we need more emails from you readers, get on it!):
“Let me tell you about how I felt about this before reading your article: If the roles were flipped, and I asked someone their rate early, and then they politely redirected me, I always thought it was a slightly adversarial move. I assumed that they wanted to have extra time to suss out how much they could charge me. That was of course never a deal breaker in and of itself…it just activated my defense mechanisms a little bit.
Now that I’ve read your thoughts, I realize that there’s a very non-adversarial way of looking at it, too. You want to get the prospective customer’s sentiment primed with the value you can deliver before activating the rational number-crunching part of your brain. And I can see, from the way you put it, that this can be a service to your customer (you are helping them reach a conclusion they will be happy with).
So here’s my question: If a client asks for the rate too early, is there a gentle way of framing the redirection such that you could also indicate it’s for the greater good of both parties that you want to talk about it later? A way to indicate that you are avoiding the question for now, but not for adversarial reasons?”
Rachel: You got it exactly right when you described priming the emotional side of the brain with value before activating the logical side with numbers.
Any purchase decisions of this size are very emotional, and the relationship between a freelance developer and a client requires a tremendous amount of trust. When it comes down to it, we always try to treat our customers like friends (that’s really the key to building a strong referral network), and it starts with the first sales call.
In my experience, one of the best ways to handle an early question about rate is to say:
“It really depends on the scope of the project.”
If they push you again, you can give them a range (making sure that the top end is above what you want to charge them, and the low end is no lower than your anchor rate), and tell them it depends on the size and length of the project.
I’d be sure to also give them a frame of reference if you share your rate (which can be tough without project details), but you can always say:
“I’ve seen people spend anywhere from $X to $X on an MVP (iOS app, Shopify site, etc.).”
A lot of clients want to get a ballpark estimate on a first call, but the reality is there’s really no good way to do this. Either you’ll over-estimate and they’ll decide you’re too expensive, or you’ll under-estimate, and set the bar unrealistically low for what the project cost is likely to be (which can cause problems downstream).
And it’s ok to be honest with your clients about that – I think people actually really appreciate it when you’re up front about wanting to give them the most accurate estimate possible (which sometimes means they’ll have to wait a little while).
I wouldn’t avoid the question entirely since that may make them wonder why you don’t want to share anything. Just give them a taste of what they want to hear, and make it clear that you’ll have more info for them soon. This way it isn’t adversarial or cagey; you’re just trying to be a good advisor to them, and give them real info they can use to make decisions.
Again, it all feeds into building your credibility and value. So while it might seem counter-intuitive, being honest about why you’re not giving a full estimate yet can actually create more trust, and get them to pay you more in the end.
Back in 2010, when Dan was new to software consulting, he charged a quarter of what we do today. And our income was sometimes touch-and-go.
We’d make bank (and burn out) one quarter, and then have a month with no business.
We wanted to make more and work less. But since our income was unpredictable, it was tough to increase our hourly rate because we couldn’t risk having clients say “no”.
Finally, we asked ourselves:
How do I charge more without tanking my freelance business?
Whether you’re not sure what you SHOULD be charging, or worried about losing clients if you do charge more, you’re in the right place.
In this post, we’re going to share…
What hourly rates you should target, and exactly how to test raising them
How to cultivate enough leads to lose clients safely
Negotiation strategies that’ll change the game for you
Psst…want our “Raise your Rates” workbook? It’s a free download you can get by clicking the button below. 🙂 It’s a great way to put these tips into action so you can start making more money soon.
Ultimately, our goal here is to put you in control of your income, so you can focus on doing the work you love, with the work-life balance you want.
So let’s dig in.
How do you start to raise your freelancing rates?
Last week, we talked about the importance of finding an anchor client (a reliable, long-term project). Anchor clients give you consistent income – and when you have a safety net, you can start to experiment with increasing your hourly rate.
Now here’s the thing: for the time being, you’re only going to want to raise your rates with new clients. Don’t worry, you’ll get there with your existing clients too, just not right away.
Without further ado, our tried-and-true formula for raising our rates:
Figure out what you’re worth.
Increase your lead generation.
Now, you can get some degree of success by pulling any of these 3 levers. But to really grow your income, you’ll want to implement all 3.
Before you can charge more, you need to determine what you’re worth.
Basically, there are two good ways of raising a price: 1) Decrease the supply, or 2) Increase the demand (or both). In the next section, we’ll get into increasing demand, but when it comes to what you’re worth on the open market (i.e., the supply), this can be based on a few things:
For example, if you check out salaries on Glassdoor.com, you’ll see that today, iOS developers tend to get paid more than than backend developers. That’s because there just aren’t as many of them.
Get a feel for how your niche impacts your unique “supply” by doing a quick search for jobs with different specialties.
How much is Google paying Android app developers vs. PHP web developers? How many job listings can you find for Java experts vs. iOS developers?
If jobs with your area of expertise are few and far between, you’re probably in a position to charge more
There are a ton of PHP developers in the market, so the salary of entry level web developers in this niche can often be quite low.
However, if you’re an incredibly experienced PHP developer, you might be at the 99th percentile for skill, and can command a way higher rate than your average iOS developer (even though they’re probably paid more than PHP developers generally).
Now, assessing your skill level can be trickier than figuring out the size of your niche, because it’s a little more subjective.
Search for common programming problems developers encounter in your field. Ask yourself:
How easily can I solve them? Have I already written scripts or tools to address them? Am I coming up with the same solutions as well-known experts?
And, rather than looking at how long you’ve been in your field, ask:
How many apps have I shipped compared to other developers? Do I have experience with a wide range of techniques within my area of focus?
Now, the skill aspect of your value is particularly important, because it’s the one part of your value that you can easily control at any stage in your career. So keep that in mind if you want to give your income an extra bump, even after implementing all 3 strategies we’re covering today.
If you’re looking at clients locally, chances are you’ll get paid a higher rate if you live in places like SF, LA, or NYC.
However, one of the benefits of being a programmer these days is that a lot of work these days is remote. In fact, I’d say 75% of our client work is remote.
So if you’re shooting for rates above $150 / hour, you may want to focus your lead generation on larger cities – though this certainly isn’t a hard or fast rule, and we’ll talk about why in just a bit.
Now that you know what you’re worth, it’s time to put that information in your back pocket.
Because the reality is, in your case, the “supply and demand” curve is on a really small scale.
Practically, that means that when a client is choosing who to work with, they generally have very limited options and subject-matter knowledge – and therefore don’t have a birds-eye view of what supply really looks like.
And to be frank, they care less about the going rate for developers like you, and more about what they can afford to spend (though we’ll talk about ways to flip this around in a bit).
Need an easy way to calculate what you should be charging? Download our free workbook for an easy-to-use formula.
With that being said…
The best way to bump up your rates is to increase your demand.
Here’s the thing: if you have enough inbound leads, you can secure rates that are even higher than what you think you’re worth.
Because if you have enough demand, someone in that pool is going to agree to a really high rate. Some won’t, and that’s ok, because the idea here is to get so much inbound, you can say no without fear.
As a freelancer, you have the ability to “artificially” increase your demand.
This just means that you put yourself in front of a lot of people. Show them that you exist.
This not only gives you some “street cred” (which will help your leads convert to sales), but it’ll increase the sheer amount of inbound coming your way.
And the more people who want to work with you, the farther you can push your rates (and the more wiggle room you have for testing them).
Some practical tips for getting in front of people:
#1. Hit up your network.
One of the best ways to get inbound is to stay top of mind with people who already know you.
This can be anyone – an old friend, or someone working on something you’re interested in. Contact them and get together for coffee. Dan does this a lot, and most of them are with friends or acquaintances we haven’t seen in a while (this method works really well for him because he’s more introverted).
Now, not every coffee has to be a direct step towards a business arrangement. In fact, most of them won’t be – so you should go into them without any expectations.
But trust us – if you spend a few minutes talking about what you’re working on, your network will remember. And as soon as they make a connection, you’ll get that referral.
Here’s the thing: While it might take some time for these leads to come in, word of mouth is the best way to acquire really quality clients.
So be patient, and keep putting yourself out there. If you keep connecting with really great people, chances are they’re going to send you clients you’d enjoy working with.
#2: Hit up someone else’s network.
Over the years, we’ve developed a list of partners that we recommend through our consulting practice – from graphic artists, to lawyers, to web and logo designers.
We send these folks to just about everyone we work with.
It’s great for us, because we can provide extra value to our clients outside of the services we offer directly, and it’s great for our clients because they know they’re hiring talent they can trust.
One of the best ways to promote a consistent pipeline is to partner with people with complementary skills, and get on each other’s referral lists.
How to find them? If you’re an iOS app developer, Google iOS app designers and find someone whose work you love. Reach out with a compliment, comment on their social media posts, and start building some camaraderie.
Eventually, if you vibe really well, talk to them about referring clients (always offer first, without asking – chances are they’ll be happy to send people your way as well).
#3: Check out some Meetups.
I’m is more of an extrovert than Dan – so I love going to meetups and checking out new groups. This can be a great way to meet people who are in your niche, or are looking for someone in your niche.
Try to pick a group with some folks that have a common interest with you. This makes it easier to connect and make an impression.
One of my favorites here in Austin is the Female Founders group. It’s chock-full of other entrepreneurs, so I’m able to get great tips to use myself, and connect with women running companies that need tech.
Another tip? Stay open-minded. Often people will attend meetups that are adjacent to their own niche, so you never know who you might meet.
For example, Dan met the founders of The Black Tux at a developer-focused meetup in Santa Monica. They needed a developer, so that’s where they were.
#4: Boost your SEO.
While in-person and phone contact generally have higher conversions to contracts, SEO (search engine optimization) can help people find you organically.
If you don’t have a website already, build one.
If you haven’t picked your niche yet, start to focus and build a blog to share your expertise.
One word of caution:
When folks don’t come to you through known channels (like word of mouth), it can be harder to tell whether they’re good to work with. So just make sure you vet them a little harder. Even a high rate won’t make you happy if your client is a terrible person to work with.
Now that you have some leads, you can start testing out different rates. But don’t be hasty – slow and steady wins the race here.
Feeling overwhelmed? Yeah, I know this is a lot – but you don’t have to do everything at once. That’s why we created the “Raise your Rates workbook so you don’t forget any of the steps in this blog post.
Brush off those negotiation skills – they’re key as you raise your rates.
Price is a sticky subject. It can be really tough for clients to reconcile the budget they want with the true cost of a product – and to figure out which developer is the right fit.
As a freelancer and salesperson (yes, salesperson), it’s on you to navigate these murky waters, and guide the client to their beacon of light: you.
But before we get into the psychology of selling, let’s talk pricing strategy.
Try an iterative approach.
Start with your anchor rate – let’s say $50. With each new project, trying pushing your rate up one tier (we’d ladder up with $75, $100, $125, $150, $175, $200, $250, $300, etc.).
Read the market. When people start to say no with greater frequency, you know you either need amp up your value, improve your negotiation skills, or lower your price.
Stick with one price point for 3-6 months. Wait to test a higher rate until you have enough inbound to minimize the risk.
Weigh your desire to work with someone with the desire to raise your rate. You don’t want someone you’d really enjoy working with to not be able to afford you. It can be a lot easier to experiment with higher rates for projects you’re not as jazzed about. If they end up saying yes, that’s great – you’ll make a ton of money. And if they say no, you’ve tested a theory, and it wasn’t a project you really wanted to work on anyways.
Sounds easy, right?
Well, it can be. But your success can be hugely impacted by how well you negotiate. Not to fear – we’ve got you covered 🙂
1. Take your negotiations slowly.
The biggest mistake people make when they get inbound is jumping into things too quickly.
In a way, it’s a lot like dating – you don’t want to get into any touchy subjects until you decide you like each other.
So, if the client asks what your rate is off the bat, you want to steer the conversation into another direction.
First off, figure out what their project is all about. What do they want to build? What’s been done so far?
This is an opportunity for you to let your knowledge shine. Show them you know what they’re talking about (ask a good clarifying question, or give them a piece of off-the-cuff advice).
You want to start building some credibility so that when you do talk about price, they’re already bought into your value.
2. Focus on absolute price and value, not hourly rate.
Most people are focused on rate as a measure of cost, when in reality, rate x time is what people actually care about.
So when you’re sharing your hourly rate, NEVER say it without including the number of hours a project will take. This way, you’re priming your client to think about absolute cost.
What if someone asks for your rate before you know how long their project will take?
You respond with the classic: “It depends.”
A perfectly acceptable response is “That depends on how long the project takes”, and follow up with a request for project specs.
If they really push you, you can modify that to something like: “My rate is anywhere from $75-$150 / hour depending on how long the project takes (with the lower rate for a longer project).”
Make the top end of the range the next tier up from what you think you’d actually bill them, so the “real” rate will seem less expensive. relatively.
If you have a fairly good sense of how long a certain class of app would take, you can also say:
“For other apps I’ve done like this in the past, they’ve taken me anywhere from 50-100 hours. So in total, it would be X.”
People really care about total cost in this situation – they don’t actually care about your hourly rate (even though they think they do). Keep the conversation focused on overall value, not rate.
3. Prioritize value over budget.
Never start a negotiation by asking a client for their budget.
Now, this isn’t to say that budget’s unimportant. In fact, once you agree on a project, it’s critical that you stick to your clients’ budget and keep them informed on cost.
But if you bring up budget too early, you’re basically telling your client where to cap the value of your work.
The moment they put out that number, they’re expecting you to come back with something lower.
A better approach is to start with a proposal matching the value of the product they want to make, and let them come back to say that it’s a little too expensive.
Now you’re leading the conversation, and can have a back and forth about how to align the product with a cost range that’s comfortable for your client.
This is the point where we like tell a client what features of their product have lower ROI, and what could wait for a future release. This way you become an active part of the product development process – not just a bystander who says yes to everything.
Need a recap? Use our “Raise your Rates” Workbook to figure out where you’re running into trouble with your negotiations, and how to get them back on track.
When it comes down to it, your rate is whatever someone is willing to pay you.
And the only way to figure it out is through trial and error.
Sometimes, you’ll be shocked at what people say yes to. Part of being a successful consultant is getting used to that.
And get realllly comfortable with the idea that the value you provide is very high, and that people are willing to pay a good amount of money for your expertise.
Because you need to believe it before your clients will.
Just don’t forget to deliver on the value.
Getting your clients to accept a higher rate is only step 1.
Now you have to deliver the value you promised them.
To some extent, your rate is based on how skilled you are, and how good you are. But if you don’t provide enough value for the price people are paying you, you’re going to get fewer referrals, because you’re too expensive for what you provide.
So stay tuned, and sign up for our email list. Next week, in Part 3 of this series (Make More Money as a Freelance Developer), we’ll be covering 5 innovative ways to get paid that can make you the big bucks (yes, we’ve used all of them).
Want us to cover a topic or answer a question in our Friday Q&A? Email me at firstname.lastname@example.org.
Imagine a perfect world, where clients have unlimited budgets for software development, and are all amazing humans.
Sounds pretty great, right?
Unfortunately, while it is definitely possible to work only with people you love, the reality of freelancing is that your clients are generally tight on cash. So…
In a world where there’s a ceiling on what clients are willing to pay, how can a freelance software developer make more money?
When Dan first started freelancing, we thought there were two ways to make more money: Take on more work, or ask for more cash (the first of which leads to burnout, the second to a resounding “no”).
But over 2 years of struggling (I worked a grueling corporate market research job to pay the bills while Dan consulted from dawn til’ dusk — i.e., midnight), we hit upon 3 keys to success that completely changed the game for us.
At first, we were planning on only writing one post on this, but it got so long that we had to break it into three parts. Today we’re covering Part 1. Sign up for our email list and we’ll ping you when we publish Parts 2 and 3.
First and foremost, if you want to start making more as a freelance programmer, you MUST…
1. Find an anchor client.
What is an anchor client, and why do I need one (or more)?
Here’s the thing: when you’re self-employed, you never want to be in a position where your current negotiation predicates your next paycheck.
Practically speaking? The best thing you can do to start increasing your income is to give yourself enough of a safety net to take some risks.
Enter, the anchor client.
An anchor client is basically a longer-term project (say, 6-12+ months). Anchors are dependable, have consistent, fairly predictable work for you, and pay you a lower rate than what you’re targeting.
The best thing you can do to start increasing your income is to give yourself enough of a safety net to take some risks.
Now, this might seem counter-intuitive. But the key to maintaining an anchor client is giving them a really sweet, long-term deal that minimizes the risk that they’ll leave you.
Because if you have one anchor client, you gain negotiating power with everyone else.
If you DON’T have an anchor client, it can be really easy to just accept what people want to pay you. The fact is, it’s hard to hold your ground when you don’t have a fallback — because your livelihood, home, and maybe family depend on it!
This is key if you want to push your rates higher for the longer-term.
I know, this might feel risky – that’s why a lot of people don’t do it. It’s also why a lot of good consultants go out of business (that, or they apply their anchor rate to everything, and don’t apply success key #2, so stay tuned for next week’s post).
How do I find an anchor client?
By the time Dan had been consulting for about 2 years, we were getting a little bit fed up with the unpredictability of our income. Dan will be the first to tell you that he’s an introvert, so it’s no surprise that I had to force him to go to a Meetup in Santa Monica (we lived in LA at the time) — to try something, ANYTHING, different.
To be honest, identifying which projects are long-term is the hardest part of finding an anchor client, but there are a few ways to do it:
1. Treat every new client as a potential anchor — they might just become one.
If you get lucky, some of your clients will take off. We’ve found that the best way to pick winners is to assess potential clients like an investor would. Look for a rockin’ team that feels right — they’re going to be around for longer, they’ll be more successful, and they’ll have more work for you.
Some questions to ask yourself when vetting clients include: Is this project likely to grow? Could I work with this person / team for more than a year? Is there a viable business model? (you do want to get paid, after all)
The best way to pick winners is to assess potential clients like an investor would.
If the answers to all those questions are “Yes!”, there are a few ways to work with these clients longer-term. We’ll talk about different incentive and pricing models in a future post, so be sure to sign up for our email list to stay in the loop when we get around to that (it won’t be long). 😀
Need more inbound client leads? That’s coming soon as well.
2. Find a successful company in a non-tech business that wants to get into apps.
These days, it’s becoming table stakes that EVERY company—even traditionally non-tech ones—have an app or web presence. A perfect example of this are service-based companies, like HVAC & plumbing (we’ve worked on apps in both of these spaces ourselves).
A lot of these businesses are finding that they can’t stay competitive without an app to streamline their operations in field, or a way to make services that are unintuitive to customers (e.g. pricing a new part for a pipe) more accessible.
But since tech isn’t their core business, they’re generally not looking for full-time developers (nor can they afford them).
What they ARE looking for is someone who can take then into the age of apps, for a price they can afford. And they’re going to need ongoing help for bug fixes and new features, which makes these types of companies the perfect anchor clients.
How to find them? Go to some local meetups for service-based industries and listen to their challenges. Pitch yourself to solve them. You can also do this online if you find the right forums (Facebook is a good place to start for industry groups).
Take note: people in service-based industries prefer to get to know you face-to-face. That’s how they do business, and it’s what they trust. So swap your loungewear for your jeans and go meet them.
3. Find a successful company in the tech space with a small development team.
Once you’ve figured out what makes YOU unique as a programmer, you can start to identify companies that value software, but don’t have any applications matching your skillset. These potential anchor clients are often even easier to sell because they already “get” your value proposition — you just have to convince them you’re the right person for the job.
One example of this might be a company whose primary business is based in a web application, but wants to starting offering mobile apps.
For products outside their core business, smaller companies often prefer to hire a freelance web developers vs. a full-time employees because it’s significantly cheaper for them.
To meet these folks, I’d recommend starting local. Check out groups for founders, CTOs and even other developers. You can also search for lists of larger startups / smaller companies in your area, and do a quick Google search to see whether their business has a gap in offerings that YOU might just be able to fill.
While this will obviously depends on your skillset and experience level, a general rule of thumb for charging as a freelancer is:
Minimum hourly rate = full-time salary divided by 2,000.
So, if a full-time software developer in your niche and geographic area is getting paid $150k / year, your hourly rate as a freelancer would be $75 / hour.
I have to stress this—but this is the absolute minimum you should offer people. So if you can’t afford to say “no” to any of your inbound at this point, go with that as your starting rate for anchor clients.
In fact, I’d actually go a little bit higher in case they want to negotiate (and they may). This way, you have some wiggle room to tell them that you really like the team and / or are willing to be flexible on rate to make it work for their budget. Of course, this is a choice that’s up to you and will depend on who you’re dealing with and your specific situation.
At this stage, it’s more important to secure at least one dependable anchor client, even at a lower rate. Wait to play hardball with your inbound leads until you can walk away without any negative repercussions.
The ideal situation is to have 1-2 anchors that provide reliable work and a healthy cohort of clients to supplement that. The idea is that one of them could become a replacement anchor. If, for whatever reason, your current anchor drops, you can always pull up one of the others.
So…what’s the next step to getting paid more as a freelance developer?
Feature creep. Scope creep. Slow and stealthy, this can take you by surprise if you’re not careful, and is a major driver of development costs.
Be wary of death by 1000 cuts. When building software, time and cost directly correlate with the features you want to include.
Picture this: Each feature you’ve carefully designed is simple, and has real value for users. But before you know it, your budget has doubled and you aren’t sure how you got there.
So how do you avoid this? This is a tough one because as a startup, you’re constantly evolving your product ideas. Changes are normal, and important, because they’ll get you closer and closer to the right product to test your market. Don’t be afraid of this.
As you go through product design, wireframing, and visual design, keep asking yourself the following questions:
Is this feature necessary for my MVP to work?
Is this feature part of the core value proposition of my product?
If the answer to either of these is “no”, consider putting that feature on your product roadmap for a future release.
Remember, by launching with a slimmed down MVP, you can test your idea with the market without too many sunk costs. It’s easier to scale up your product once you KNOW what to include, than to re-work what you THINK your market wants.
One of the top mishaps we see with startups getting off the ground is trying to build everything but the kitchen sink. At this early stage, it’s easy to dream big about what could be – those sleek UI elements that’ll jazz up a user’s experience, that nice-to-have that would really make the product pop, and the handful of features needed just to meet comp. You’re vision-boarding what your business will look like – which naturally means that you’re thinking about those key market differentiators, and the polish that you’d expect from a fully-fledged product.
But watch out – while this is all critical to making your business a long-term success, trying to building too much for an MVP can kill your product.
MVP = Minimally Viable Product
Consider the Pareto principle. In this case, we tend to see that 80% of the action happens in 20% of the product. That 20% is your MVP, and will capture most of what users will ultimately get to do with the product. The other 80% may be necessary to the product’s ultimate success, but isn’t necessary for launch. Ask yourself – are these features necessary for the product to be usable at launch? By necessary, we mean will the product cease to function without them or lose its core value proposition? Or could they be added in V2 or V3?
A Lean, Mean, MVP Machine
So why does this all matter? Why not just build the product as you envision it for round 1? A few reasons for this: 1) Time, 2) Cost, and 3) Investment.
Time: The longer you take to get to market with an MVP, the longer it’ll take you to start turning a profit, and the more runway you’ll need to self-fund.
Cost: The more features you add, the more expensive your MVP will be.
Investment: The purpose of an MVP is to test the market – do they really want your product? What do they like / dislike? Is it solving the problems you thought it would? If it turns out you’re wrong, by building an MVP, you won’t have invested all your $$s in a product that isn’t quite right. It’s easier to add features that you KNOW are right, rather than test features that might be wrong and have to go back and re-work them.
Ultimately, your biggest asset as a startup is your ability to be fast and flexible. You may not have all the money in the world, but you can do things quickly to respond to the market. Learn something new about a competitor? Change your product. Partnership opportunity just came up? Add the one feature they need to make it happen. Not quite sure what customers want? Test your hypothesis on the cheap, then pivot if you’re wrong.
The purpose of an MVP is to test an idea with your market. Building a lean MVP saves you time and money, and gives you the flexibility to change course if needed. Features can always be added later when you have the resources to do so, and the market validation that you should.
Ready to streamline, but don’t want to lose track of those extra features? Sign up for our email list to get a preview of our upcoming post on how to create your product roadmap.
Let’s break it down into 3 pieces: 1) Illuminate, 2) Iterate, and 3) Communicate.
To kick off the design process, you’ll first want to illuminate your product for your designer. Your goal here is to “shine some light” on WHAT the product is, and HOW it should look.
WHAT: What’s your elevator pitch? What’s the value proposition of your product? How are you different than your competitors, and what about this do you want to come across?
HOW: At this point, you probably have a sense of what your app’s design should look like – either in visual terms, or at least what emotions and thoughts you want it to evoke in your users. You may even have some examples of things that you like / dislike. If you have one, share a portfolio with your designer showcasing examples of visual design that “feel” like your app. These can be other apps and logos, screenshots of UI’s that you love, pictures of street signs, advertising, or even storefronts and architecture that just feel right.
Try to pinpoint what about each of these elements appeals to you – is it because the blockiness of a building communicates strength and that’s part of your brand persona? Is it because you like a bright color for an app in the kids space?
And don’t forget to include what you don’t want your design to include – namely imagery or colors used by competitors.
As with every creative process, you should expect a certain amount of back and forth with your designer once you’re ready to kick off. Now that you’ve shared your vision for the app, it’s time to iterate early, and iterate often.
Typically, you’ll be able to react to designs at several different stages (and in fact, this is something you’ll want to ask about when interviewing potential partners). Ideally, you’ll get to first see a few napkin-sketch options for color palette and theme; these are an easy way to provide some high-level direction about where you want to go with the design. Then, it’s often a good idea to have your designer mock-up what a landing page might look like before diving into the rest of the site. This will help you get a feel for how things will look in more detail, and can make some higher-level stylistic tweaks before applying that look-and-feel to the rest of the site.
At this point, your designer will create designs for every screen of your application. Because your app might have anywhere from 5-50 screens / pages, it’s best to communicate frequently (and in detail) before getting to this point. It’s much easier to make stylistic changes earlier on – saving smaller, page-specific changes for this last stage.
So iterate early, iterate often, and….iterate positively (onto step 3).
Design work, which can be based heavily on feeling, intuition, and creative inspiration, is personal in a way that programming is not. This is what makes custom design so special, and powerful. It’s important to keep in mind that when you iterate on designs, effective communication largely means focusing on the positive.
Two reasons for this: 1) Feedback resonates better, and more constructively, when it has a positive slant, and 2) It’s easier to steer your designer towards the right direction than away from the wrong direction.
Chances are, you already intuitively understand #1 – we’ve all been the recipients of constructive (and not-so-constructive) feedback, so let’s talk about #2. When it comes to designs, you’re presenting a concept with an essentially blank slate. That designers can turn something as nebulous as an idea into something that resonates with users in a visual way is to us, quite frankly, amazing (not being designers ourselves). And to get there, we’ve found that it can be tremendously effective to focus on what you do like, rather than what you don’t like.
Think of it like a map. There are an endless number of directions a designer can take a product – so by pinpointing what you do like, it’s much easier to continue turning down the right streets, to arrive at just the right destination. That’s not to say you shouldn’t call out what you don’t like; avoiding the bad neighborhoods can be equally important to get to that simple, elegant, something special. Just be careful not to get stuck in the weeds.
So…there you have it. Illuminate, Iterate, and Communicate (positively). Now have fun!