How to support the show
Patreon
Prices subject to change and are listed in USD
- Support the show from as little as ~$1/month
- Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
- Help support the HTML All The Things Podcast: Click Here
Learn with Scrimba
We receive a monetary kickback when you use our link
- Learn to code using Scrimba with their interactive follow along code editor
- Join their exclusive discord communities and network to find your first job!
- Use our affiliate link to learn more
Show Notes
Tip 1: Present a human solution
- Present a solution in a consumer-friendly way
- This is a presentation of what you’d like the end product to look like, not how many databases and domains you need - Avoid deep technical discussions unless there is a member of their technical staff there
- Even if there is a member of technical staff there, present your solution the human way, then add some technical details directed at the tech experts - Don’t oversell, but have salesmanship
- Don’t present the customer’s problem as your problem (ie Oh man that’s going to be really challenging, what I think you should do is X instead because doing all this is going to be nearly impossible)
- In some cases you might have to speak the direct truth about the customer’s problem, they may straight up not have the employees or budget to do what they’re trying to do - Show and Tell goes a long way, especially when the customer request is similar to what you’re showing them
- Show off previous projects (with permission)
- Show off portfolio projects
Tip 2: Answer questions in short-form to start
- When your customer has questions, answer the questions in the shortest to-the-point fashion as possible
- Long-form answers can take over meetings and get everyone bogged down in something small
- If a question demands a long-form answer, I recommend answering in a short-form way being clear that you’re giving the short answer, but offer to give a longer answer at the customer’s request
Tip 3: Don’t be afraid to push-back
Business Note: This is a controversial tip, as some people believe the customer is always right, and therefore you’re there to implement the tech that the customer asks for. It’s not on you if what they’re asking for is something that they don’t need or can’t support reliably. You have to decide which type of business you want to run, for us we believe…
- You should push back on parts of a customer’s project, not when they’re too much work for you, but when you have a legitimate concern including:
- Budget worries
- Employee constraints (ie not enough people to support a feature)
- You believe there’s a misunderstanding in what they’re asking for (ie they ask for 2-factor because they hear that’s secure, but they don’t know what it is, and aren’t tech savvy enough to use it without assistance) - Push back with evidence and inquiry
- Inquire: Ask questions as to why your customer wants a particular feature that you suspect won’t help them in any way
- Evidence: When you push back, offer evidence to back up your pushback (ie You’ll need to pay for regular maintenance and we’re already at the max budget) - Offer workarounds that compliment your customer’s goals (ie Don’t use an inhouse ecommerce solution, go to Shopify)
Tip 4: Set Expectations for everyone
- Your customers may expect too much of you, and you may expect too much of them
- Set expectations in a positive way
- You don’t want to say something like “Oh that’s way too much work for me, I’m out”
- Instead say something like “We’re only a two person agency so that will take us longer to develop, I hope that’s ok” - Ensure you learn everything that your customer expects from you beyond just developing a project including:
- Long-term maintenance
- Future calls for help
- Response times
- Etc. - On the customer end check on their capabilities versus your expectations
- They may promise a lot of content and written material but never deliver it, leaving your new website filled with sample text for months
- They may want a full ecommerce system for a product that is so early that it’s years out - making the system you made dated or in need of maintenance despite it’s lack of use - Set clear logistical expectations:
- Response times
- Payment schedule
- Deliverables (how they’re delivered and when)
- Downtime for maintenance and updates
- Payment type (package deal, hourly, subscription)
Tip 5: Mitigate and Define Scope Creep
- Some scope creep is probably inevitable (unfortunately)
- Excessive scope creep can easily kill a project
- Defining what scope creep is and what the consequences are is key, such as:
- More features = more money
- Adding to the original scope will push the deadline(s) - Define your process and how scope creep is defined and expressed to the client:
- Make a quote with a scope of work and have it approved
- Doing anything additional to the original scope of work may be considered scope creep and incur consequences
- Clearly tell them how you will inform them of scope creep (ie you’ll send an email saying that whatever they want to add may incur an additional charge and will push all deadlines by a certain amount)
Links
- Michael LaRocca
- Author of the Self-Taught the X Generation blog, at selftaughttxg.com
