Don’t apply for the job; just do it
Resumes are inefficient. They’re a dated tool created to summarize your life and experience because it used to be difficult to find out anything about a person. Today you are searchable online and have an online profile that speaks volumes about your experience and personality. People have tried to replace resumes with websites and other products in an effort to simplify the recruiting experience. However we still live in a world where resumes are required, if not crucial, for the vast majority of jobs. So when I sat down to think about what my resume would be like, I was continuously annoyed that instead of actually getting to do the job, I had to describe how I was qualified to potentially do it. I tried writing and got bored, so instead I decided to do my job approach my resume like my own product.
Market Research
First things first — I need to answer some key questions: What am I doing? What is the goal? Who is the user? What do they care about? And - what is their problem? I need an idea of what user and market I’m dealing with so I know what to address. So let’s do some brainstorming.
As you can see, I looked at a few ways to think about what I’m trying to do and realized that the driving goal is really to get a job. And not just any job, but a job I want. As such, I’ve identified the goal for this product is to build a resume for a job I want. Now how do I do that.
This is where some research is required. I need to find out who the user is, what their goals are, and what their pain points are so that I know how to address them. So, like every quality researcher looking for reliable information, I turn to Google.
With the wealth of information and advice out there, the initial challenge really is identifying what information to pay attention to and what ideas to ignore. After going through reviews, blogs, guidance from experts, and spending a bit too much time in labyrinthine rabbit holes of Reddit, I made some basic discoveries and gleaned some insights. There are a wide variety of opinions however.
There are a number of disparate preferences and recommendations reflecting different user experiences, industry exposures and ideas of what makes a ‘good’ resume. Some prefer the descriptive and lengthy, some the concise one-line summaries. Some hunt for the colorful and designy approach, others just want information without any fluffy visuals. This also speaks to the asymmetrical processes used by different organizations to deal with resumes, and the different design preferences.
Across all of these opinions I was able to make some key assumptions about my target user, and their major pain points. It became clear that they read a large number of resumes in a limited period of time, that they need to be efficient in what they can capture and interpret their relevance, and that no one likes a typo (that last one may actually be the most common factor of all). To be able to address these I need to focus on something that’s concise, easy to read, impactful, and spell checked.
Ok, so I know what I’m trying to do, but how do I do it?
Managing Resources
Now that I’m getting to building, some new questions come up: What skills are required? Who is available as a resource to work? How do we communicate and coordinate work? What does the team look like? What work needs to be done? Without knowing what is required and what is available at your disposal, you can’t make a realistic plan for how to move forward.
In this case, it’s just me who can do the work. That settles that (sometimes this is the simple part).
Since I’ve already done the initial research so next I need to design and build my resume, then test, release and iterate on it. So let’s get to that.
Building, Launching, Iterating
As I said, I’m using this approach to build a better resume, not an entirely new job process. Luckily, resumes already exist so I can start with a base format and tweak it. I can think of my first draft as a test and instead of sitting and working on a completing a fully ‘robust’ product before I launch, in this case I find more value in building quick, launching and iterating.
First I find pre-designed resume templates that I like and think could address the main desired features identified; being concise, easy to read and impactful. Starting with a few diverse designs I can try to use data to support my hypothesis about what type of design has more impact. With that, after defining some core messaging about myself, it’s just tweaking both design and content to maximize interest and appeal to get to a stable enough product for an actual launch i.e. showing people who can have an impact on my career. This arguably takes a longer period of time, but by using what I know about my user and their pain points as a guide, I‘m able to start off on solid footing for a first build.
And we’re ready to go! At first I’m looking at a slow launch by releasing to job portals to track hit rates and for feedback to make the resume more robust before targeting the higher priority and more desired recruiters, companies and markets. With each bit of feedback data and insight I gather I continue to iterate and tweak on overall messaging, layout, importance of some components and even on specific lines of content to include. As I lock in some of the major aspects the changes tone down to be less monumental (at this point it’s tempting to call it A/B testing, though I don’t think the term is wholly appropriate due to the low volume). Regardless, the user insights and market beliefs established from this are key for guiding my progress.
Though the product/resume is now released and generally available, the work is never done. At this point I consider the product launched and at a stable place but it still requires a constant effort to manage, review and respond to feedback and performance out in the field. As I get more data and feedback I can continuously improve to further improve the impact and efficacy of the product (i.e. let’s get that job).
There are a number of ways to approach managing a product, often depending on the factors in the market and the resources available. This is just one way based on some design thinking principles that I’m testing out, focusing on iteration and customer feedback/data to guide development to best meet the needs of the user itself, while getting closer to the ultimate goal.
Savar works in product management, and spends far too much time finding new content online.
