Startup Artist

I teach entrepreneurs and coders how to communicate

Always do this BEFORE you talk to a programmer: mockups

“They just don’t GET IT!” – everyone who ever talks to a programmer about their idea

Have you ever tried talking to a programmer about your idea and became frustrated when they didn’t seem to understand?  Or even worse, they pretend they understand, but you can tell that they really don’t.

Why can’t they just UNDERSTAND you?  Isn’t that their job?

Actually, no, it isn’t.  Their job is to understand the technology.  YOUR job is to get them to understand you.  It might sound a bit unfair, but the upside if that if you learn to talk to programmers, you can save tens of thousands of dollars (not to mention hours of time and frustration) turning your vision into a reality.  That’s easily worth the extra upfront work you’ll have to do.

Whether you are trying to launch your own website (or app) or working with a developer at your company, the best thing you can do is bridge the gap between you is by creating a mockup (aka a wireframe) which details what you have in mind.

In fact I’m going to go ahead and tell you this: do NOT approach a developer without a mockup.  To do so is wasting time – both yours and theirs.

For the rest of this article, we’re going to work towards making a mockup for a time-tracking app for freelancers.  It’s simplistic, but you can build on it to create your own mockup.

Step 1 – decide on a tool

There are dozens of tools you can use to create your mockups: Microsoft Visio, Adobe Photoshop, Google Doc Drawings, wireframe.cc, Balsamiq Mockups, etc.  The important thing to note is: you should decide on a tool that is very quick for you to use, and easy for people to understand.  Make sure you can draw something that looks kinda like what you’re trying to make, and that you can add text to explain things that the pictures don’t explain.

Personally I use a blend of tools.  My early concepts are always in pen on paper.  I like to sketch a bunch of different concepts before I go electronic.  When I’ve chosen the concept I’d like to specify, I usually use Balsamiq Mockups (http://balsamiq.com/products/mockups/).

Step 2 – write down your user tasks

To organize your time and make sure your mockup covers as much as possible, you should write down each type of user and the specific tasks they’ll be able to accomplish on your website.

For our time-tracking app, there are only two basic tasks our user will need to do:

  • record time worked
  • view time worked

It’s pretty simplistic, but it’s really just a quick checklist to ensure that your mockup is covering all your bases.

Step 3 – make a mockup

This is the fun part – you get to be creative!  The biggest advantage of using an electronic mockup tool is that you can quickly create, abandon, and change anything you like on your website in a matter of seconds.  Here’s a mockup I whipped up in 30 minutes for our time tracking app:

mockup

I like to create a picture of the “default” (what the user sees when they first open your app or web page) at the top.  Then I have a row of interactions for each use case that we wrote down in Step 2.

Notice the numbers in blue circles peppered throughout the drawings.  They aren’t part of the app – they are annotations.  They provide additional information that the drawing itself doesn’t convey.  In your annotation you may include things like default values, invalid values, app behaviours and other details.

Also notice that my mockup doesn’t look very pretty.  That’s OK!  The purpose of the mockup isn’t for the LOOKS, it’s for the FUNCTIONALITY.

Step 4 – show someone (not a programmer) your mockup

Inevitably, you will miss something.  You are too close to the project, and something in your mockup is unclear or doesn’t make sense.  The best way to catch these things is to show someone who hasn’t seen your project before.  Here are some questions you should ask them:

  • what do you think the purpose of this app is?
  • who do you think this app is for?
  • what are some of the things you can do in this app?
  • anything you don’t understand?
  • how can I make this better?

Talk very little, listen a lot.  Your job here is not to explain the app, but to figure out why your mockup isn’t good enough to get the message across.  At the end of the day, your mockup has to explain the app without your explanations, so the less you talk the better.

My wife is my guinea pig.  I had her look at this app and asked her these questions.  Here’s some of her feedback:

  • “It looks like it’s for freelancers to record their time”
  • “It took me a little while to understand what client name is supposed to mean”
    • “I think it would be more clear if it said Who did you work for?”
  • “It’s not obvious that record time is a button”
  • “Where did the description go?  I don’t see it in View Time”

Good feedback, wife!  I spent another 10 minutes and updated my mockup to look like this:

blog_mockup_v2

Notice that I didn’t take ALL of her feedback to heart (I left the record time button as it was).  Even though you should listen to all the feedback, you don’t have to take all the feedback.  In the case of the “record time” button, I’ll just keep it in my head and make sure that the designer makes sure it obviously looks like a button.

Step 5 – show a programmer

You have your mockup, it’s time to show a programmer.  Here’s how you can tell if you’ve found a good one: if the programmer starts asking tons of questions and reveals that your mockup is missing a lot of details, they’re usually a decent programmer.

Don’t feel bad that your mockup is missing a lot of details (you can always add those into your mockup after the meeting).  Instead you should be happy that your first meeting with a programmer is productive instead of frustrating.  You’re starting the relationship on a good foot, and your mockup provides a point of communication between the two of you.

Conclusion

Programmers thrive on documentation, a mockup is the bare minimum that you should have.  With a mockup, you can start vetting programmers based on how they react to your drawings and start settings timelines and expectations.  If you were wondering where to start at the beginning of this article…CONGRATULATIONS!  You’ve now started =)

 

General Tips for Mockups

  • the mockup is also a great way validate your idea with your target market.  Show people in your target your drawings and ask them the same questions in step 4 (you should probably remove the annotations before you show them, though)
  • if you  have an example of a UI element that you like from an existing app or website, then include a link to it in your annotation.  (i.e. this date-picker should function similar to how AirBNB’s date picker works: http://link_to_date_picker)
  • in general, try to keep your mockups as simple as possible.  Too much information can be just as bad as too little.  If your website has a LOT of functionality, consider breaking your mockups into multiple mockups based around functionality themes or releases
  • close your eyes and imagine you’re using the app or website in the mockup.  A lot of the mistakes and missing information in your mockup can be found this way.

Comments by ReddiComments - Join the conversation on Reddit!

How to get an interview for your dream job

One of the biggest gripes I hear from technical people is the fact that their job sucks.  Good news everyone: if your job sucks, you can find a new one!

It’s a simple fix, but the fact is that many technical people don’t like the process they have to go through to find a new job.  And why would they?  There are a million places out there that CLAIM they can get you a better job – monster.com, LinkedIn recruiters, etc.  All you  have to do is send them your resume and they will find the perfect job for you, right?  WRONG!  If you’ve spent any time trying to find a job this way, you will quickly figure out that IT’S ALL A LIE.  The job of a recruiter is to make as many matches as possible, so they’ll say ANY job is better than your current position if it means that you’ll jump ship.  That’s how they get paid.

So what’s a humble technical person to do?  If you’re really serious about finding a job that actually makes you spring out of bed every morning, then you’re going to have to put in some effort.  Not just any old effort; you’re going to have to put in some TARGETED hard work that will ensure that you’ll get the kind of job you can brag about.  If that sounds like what you’re looking for, read on.

Step 1 – Make a list of the companies you want to work for

Rather than trying the shotgun approach and sending a general resume to dozens of companies, we’re going to narrow the choices down to a list of a MAXIMUM of 4 companies.  After we have our list and done our research, we’re going to send each company an extremely-targeted communication that will up our chances of scoring an interview.

You should definitely put some time into this step.  The worst thing would be to put a ton of effort into finding a new job only to find that it has the exact same problems as your old job.  Research the companies – the work culture, their successes and failures, and any other information you can find.

Pay particular attention to the leaders of the company.  Every organization, big or small, will resemble its leader.  Don’t just look at what they say, but also what they do.  You’ll find a lot of companies that pay lip-service to being people-focused and having a good work-life balance, but don’t actually follow through with their employees.

Which brings me to the next step…

Step 2 – Set up meetings with people from the companies you want to work for

You learn different things about companies when you ask their employees versus looking up news articles.  Not only is the information often more genuine, but you can also get tidbits about work culture and leaders that never normally make it out of the building.

This can seem like a difficult step, but it is 100% possible to find a contact at any company.  Once you find a contact, all you need to do is convince them to meet you.  I’ll show you how to do both.

Here are some methods to find people to contact:

  • Search your LinkedIn network to find people who work at the target company.  If you have a shared connection, ask people within your network to make an intro.  I’ve never had anyone deny me an introduction.
  • Scour the company’s web presence to find contact information
  • Subscribe to the company’s social media and attend company events to meet people
  • Find the names of people who work within a company and find and follow their social accounts

How to convince them to meet you:

This one is simple once you realize that people LOVE to be asked for advice.  That means, when you contact the company employees, you should be an ADVICE SEEKER and not a job seeker.  What does that sound like?

Dear Fred,

Thanks for the great chat the other day at [company event]. I never realized how [something from the chat you had].

I’m currently taking a look at my career, and I realized that you’d have a lot of insight on my situation. I’d love the opportunity to pick your brain and get your advice. Would you be willing to spare 30 minutes or so over coffee?

I appreciate your time and hope to hear from you. Thanks in advance,

[your name]

Now, a note on asking for advice; BE SINCERE.  You’re not trying to trick the person.  You need their advice.  After all, they have already achieved what you want to achieve: they got a job at one of your target companies.  Listen to their advice and take it seriously.

I have a very high rate of success contacting people like this.  North of 70%.  Be brave and send out those emails!

Step 3 – Extract insider information

You’ve successfully booked some meetings, now comes the hard part.  How to use the meetings to your advantage?  Since you’re the one who booked the meeting, you should come prepared with some questions to ask.  Not to worry, I got you covered.

General questions:

  • What’s it like to work there?  Do you enjoy it?
  • What are some of the biggest challenges your company faces?
  • What do you think your company is trying to achieve (big picture)?
  • Do you see yourself working there for a long time?
  • What are your biggest pet peeves about working there?

If this person is in the department that you could see yourself in, make your questions more specific:

  • What is the role of your department?  How do you fit into the big picture?
  • What are you current departmental goals?
  • What kinds of things are preventing you from achieving your goals?
  • What kind of people do you like to work with?  Why?

If this person is NOT in the department you could see yourself in, ask about it:

  • Do you interact with [department] much?  What’s your impression?
  • Do you feel like they help you do your job?
  • What kind of people are in that department?
  • Do you know someone I could talk to in that department?

These questions are just a starting point, be sure to ask followup questions to probe more deeply into the answers they give you.  Try to keep your questions open, to allow the person you’re meeting with a lot of time to talk.  I always book these meetings for 30 minutes, but if I get a good rapport going, it’s not uncommon for them to last 60-90 minutes.

Make sure you look engaged when the person is talking.  Look them in the eye and nod.  LISTEN to what they are saying.  More importantly, LISTEN TO THE LANGUAGE THEY ARE USING.

Language is extremely important.  Every company has it’s own culture, which includes language.  If you can learn the language of the company, it makes it that much easier for people from that company to understand you.  If it’s easier for them to understand you, it’s easier for them to like you.

At the end of the chat, make sure you thank the person with a big smile and a handshake.  Before you leave, WRITE DOWN the language that you heard the person use.  This is especially true for any terms they use for the kinds of jobs that you see yourself doing.  Also make sure that you write down their biggest challenges.  You’ll use these notes later when you construct your resume.

You should send a thank you email to the person you met later that evening.  If applicable, add a gentle reminder to send you the contact information for the person in the other department that was mentioned at the meeting.

Step 4 – Craft your resume

Surprised that this is so far down the list?  To do this step any sooner is a waste of time, because you didn’t have all the information you need.  After meeting with people at the company, you should know these two things:

  1. the challenges that the company/department has (and by extension, how you can help solve them)
  2. the language that people in the company use to describe those problems

You entire resume should be geared towards how you can solve the company’s problems.  As you write down your objectives and experiences (or edit your existing resume), keep the language and challenges in mind.  For instance, I had some bullet points that looked like this:

  • Specified and prioritized high-level work items at the executive level
  • Converted high-level work items to detailed tasks for product releases

After talking to people at the company I was applying for, I realized that they used completely different language to describe what I did.  So I changed the points to this:

  • maintained 6-month product roadmap by leading quarterly executive meetings
  • converted objectives in the roadmap into bi-monthly sprints

Note that the the meaning of the bullet points is the exact same, I’ve just substituted some of the words so that the person reading my resume can instantly understand what I mean in the context of their workplace.  This subtle difference can have a huge impact on the reader’s frame of mind.  I’ve ALREADY solved a problem for them – they’ve spent less mental energy on deciphering whether or not I’m fit for the job.

Keep your resume short and to the point.  Remember, this is about them, not you.  The faster and easier it is for them to understand that you are the problem solver they’ve been looking for, the better.

Step 5 – Craft your cover letter

I’m a big proponent of the cover letter, although I freely admit that it’s difficult to use one to great effect.  The key thing to remember about your cover letter is that it is giving the reader of your resume context.  In other words, it’s an additional way to connect the skills that are on your resume to the job itself.

My favourite way to do that is by proposing potential solutions to problems right there in the letter.  How that works is completely dependent on the information that you gleaned from step 3, so I won’t try to micro-manage you here.  Just be sure to keep it short and sweet!

Step 6 – Apply and apply

If you’re lucky and likeable, the contacts that you made in step 3 will help alert you to any job postings that come up rather quickly.  At that point, you have to apply twice:

  1. apply to the job by submitting your resume and cover letter
  2. apply a little pressure to your contacts in the company to put a good word in

The second step is the step that will usually get you the interview.  People always search for credibility – knowing people within the organization says a lot about you as a candidate.

You deserve it

It was a long read – are you still with me?

The point of this process is that it allows you to differentiate yourself from the crowd.  Rather than putting a minimum amount of effort into 100 applications and getting another job you don’t care for, you put a maximum amount of effort into 2-4 applications at places you REALLY want to work.

I don’t believe in settling for less, I believe in shooting for more.  You deserve a job that you enjoy, so don’t accept anything less.

Comments by ReddiComments - Join the conversation on Reddit!

My agile process: a battle-tested workflow

In a previous post, I talked about why I don’t do fixed-time, fixed-price projects.  In this post, I’ll talk about an alternative workflow that I’ve developed over the last few years.  It has, so far, been effective for teams of 2-12, and can be implemented by absolutely anyone.

First, let’s define what we’re trying to accomplish.

The Goal: to make good software quickly

…that’s it!  It might sound simple, but at the beginning of the project, you have to define what “good software” means.  In most of my current engagements, “good software” means software that accomplishes business goals, but if the software isn’t for a business, you may have a different definition.  No matter, this process will still work for you.

The Workflow

workflow

So simple, you can afford to do it yourself!

As you can see, the process isn’t complicated; only 3 phases, which we’ll talk about in detail below.  It’s an iterative process: once you get to the end, you go back to the beginning.

The important thing to note is the timeline – a maximum of 1 week per iteration.  Why one week?  Mainly because of the feedback phase; getting feedback every week ensures focus and strengthens the bond between business requirements and production.  Nothing is more frustrating than a misunderstanding that doesn’t get caught for months and leads to a ton of unnecessary work.

Phase 1: Priority Meeting

Goal: to get everyone on the same page about the work for the week

Output: a prioritized (ordered) list of work items

The priority meeting is where you review the work done last week and agree on the work to be done for the next week.  It’s also an opportunity to get everyone on the team on the same page, and re-focus the team on the overall team goals outside of their sphere of influence.

The main output for this phase is the prioritized list of work items.  This can take any form you want, from a spreadsheet to your favourite project management tool (I use wrike).  The important part is that you have the following information for each work item:

  • the priority of the work item (aka the order)
  • the person the work item is assigned to (the assignee)
  • a description of what the outputs of the work items are (I call these acceptance criteria)
  • any information that the assignee will need to complete the work item
  • (optional) the status of the work item

The prioritized list should be available for everyone on the team to view, as it’s how each team member knows what to work on next.  Because the list is ordered, any team member can simply start at the top of the list, and find the next work item that has their name on it.

A note on priorities: no two work items can share the same priority.  Priorities are discreet and unique.

A note on work items: no work item should contain more work than can be completed in a week.  Ideally, each work item should contain only enough work for 2-3 days.  If you have work items that you think will take longer than a week, then you can simply split the task up into smaller pieces.

I like to ensure that the priority meeting takes no longer than 1 hour.  For bigger teams, you may need to have multiple meetings based on types of production (i.e. high-level priority meeting for managers, priority meetings for individual teams of design, coding, marketing, etc)

Phase 2: Production

Goal: to complete the work for the week

Outputs: production artifacts (i.e. code, design files, marketing plans, etc)

The production phase is the real meat of the process, and usually takes 2-4 days.  This is where all of the coding, design, research, marketing, sales, etc gets done.

There’s not much to say about this phase except that it should be directed by the prioritized list from the previous phase.  Work items should be completed in priority order, and should only be considered complete when the acceptance criteria that are notes in each task are met.

Phase 3: Feedback

Goal: to ensure the quality of the work done during the previous phase

Output: a list of revisions to make for each task in the prioritized list

Feedback is often neglected in many organizations, but it’s absolutely vital.  Not only does it ensure the correctness of the work that was done, but it also allows you to train team members to conform to your organizations standards.  It’s a huge opportunity, so don’t waste it.  Take the time to do it right.

Everything can be given feedback, and feedback should be given by everyone.  Obviously reviews should be given for code and designs and user testing should be done for prototypes, but people often forget that even things like business and marketing plans, pitches and customer communications can be reviewed.  For example: if the CEO is working on a pitch, the best way to ensure it’s understandable and convincing is to pitch the team, and see if they are convinced.

The value of feedback is immense.  It’s easy to think that you made something high-quality after looking at it yourself for 2-4 days.  The real test of whether or not you created a quality output is if others confirm your bias.

The outputs are a list of revisions.  Keep in mind that after the revisions are made, they will also need to be reviewed before the task can be closed, so it might be best to add the revisions as work items in the next week’s priority meeting if they are extensive.

Make it your own!

What works for one organization may not work for another.  I’ve kept this workflow intentionally vague; free of specific tools, so that you can mould it to your own team.  Every time I set up this process for a new team, I take into account the team’s unique situation, and make changes as I see fit.

Remember the goal: to make good software quickly.  If you find a way to make your software better or faster by tweaking the process, then go for it!  If you find it works, I’d love to hear from you.  Leave a comment or drop me a line on twitter.

 

 

 

Why I don’t do fixed-time, fixed-price projects

It seems that fixed-time, fixed-price (FTFP) contracts have become something of an industry standard in software development, even though most other long-standing professional-service industries (lawyers, contractors, etc) typically won’t ever work under those terms.

I’m firmly against FTFP contracts for software development; I think they are bad for clients and bad for service-providers. Below I’ll tell you why.

FTFP contracts often feel dishonest

…because software is too dynamic to accurately estimate

The estimate is at the core of the FTFP contract, but software has too many unknowns to create accurate estimates.  A list of some (but not all) of the unknowns around software development:

  • scope of work
  • quality of the final product
  • maintenance requirements
  • user-interface specifications
  • changes in technology during the lifetime of the product
  • etc, etc, etc

I once had a reputation for always having accurate estimates.  How did I do it?  I applied the Scotty method: take the amount of time I actually thought the project would take, and DOUBLE IT (sometimes triple, if the requirements are particularly nebulous).

I’m not alone in this.  Software estimates are known to be notoriously inaccurate in the industry, and yet many still use them as a way to bill clients.  It’s actually pretty dishonest, in my opinion, which is why I stopped doing it.

That’s not to say I don’t provide estimates, I do.  I just explain to clients what the estimate actually means, rather than building in buffer via smoke-and-mirrors.  Then I bill my actual time, and not my estimate.

FTFP contracts cause a ton of wasted work

 …because the scope of work has to be decided up-front

Since you have to understand scope before you can create an estimate, you must lead clients through the requirements-gathering phase at the beginning of the project.  This can be a long, drawn-out process; one that often exhausts both the client and the service-provider before any actual work has been done.

Anyone who has been through this knows it’s not fun for either side.  You’ll also know that scope invariably changes – it’s near impossible to lock it down at the beginning of the project.  So what happens?  The inevitable change-of-scope dance.

The client wants something changed.  Now both the client and service-provider have to decide: was this in the original scope of work?  The client will say that it is (they don’t want to spend more money for something they thought was included).  The service-provider will say it’s new scope (they don’t want to spend more time without being paid more).  The true answer is that your scope of work was not defined accurately enough, and left some ambiguity.

What it boils down to is this: it takes effort to make changes to a FTFP contract.  Mental effort, mostly, which is what most service-providers and clients use to make a living.  Since this effort is not paid and not productive, this effort is WASTED.  It also leaves lingering feelings of resentment instead of the camaraderie that you want on a team.  Which brings me to the last point…

FTFP contracts are more adversarial and less fun

…because the contract incentivizes bad behaviour from both sides

The fact that the project is FTFP means that the client and service-provider have adversarial goals.

Client: I want to get the most work for my money

Service-provider: I want to get the most money for my work

Instead of working as a team toward a common goal (creating the best possible software product), the FTFP contract incentivizes the client to extend the scope as much as possible and incentivizes the service-provider to cut corners.  This is absolutely the WORST way to set up a working relationship, it only causes frustration and resentment.

Is there a better way?

You bet your butt there is!  Here’s how I do it: My agile process.  Feel free to discuss how you manage your projects in the comments.