Techniques: Job Stories

So, you’ve heard of User Stories. They represent requirements from the perspective of a User. But that’s not the only kind of requirement there is.

The distinction between a Job Story and a User Story is the perspective from which the story is told. Primarily, Job Stories focuses on the situation or scenario in which an action will be triggered. This shift can give additional information that might be missed in the more traditional User Story format.


The format for Job Stories is basically this:
When (a situation), I want to (motivation) so that (expected outcome).

Where User Stories focus on Who, Job Stories focus on When. Also, where User Stories state what is needed, such as a dashboard or report, Job Stories focus on actions to be performed.

It’s not that Job Stories are Superior to User Stories. But there are situations where to capture the intent of the work, you need to express it as a verb instead of a noun – or an action instead of an object. 

That distinction is where Job Stories are valuable.


Here are a couple of examples of Job Stories:

When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so I can go out to dinner with my friends.

When someone wishes to withdraw money from his/her account, the customer wants to know if funds are available, the teller wants to know if the person banks with us, so that the person requesting can received the desired cash amount.


Agile Extension to the BABOK®  Guide – section 7.4

As mentioned in the previous slide, the format is When (Situation), I want to (motivation) so I can (expected outcomes).

The Situation gives the trigger – when will this job happen?

The motivation identifies who needs to do what.  And it can involve multiple personas or actors.

The expected outcome can also be multiple.  On the previous example, expected outcome could be the customer receives cash and the teller reduces cash amount from the account.


Agile Extension to the BABOK®  Guide – section 7.4

One of the benefits of Job Stories is how this technique relates the Customer’s motivation. It can help to Think as a Customer, and build empathy.

One of the things that has struck me while studying the literature surrounding various Agile frameworks is the use of terms like Empathy in explaining the purpose of various techniques. One of the major elements required to pass the AAC exam is the Agile Mindset.  So understanding the empathetic side of the analysis is very important. Requirements are for people, and they need to reflect the motivations of the customer. Empathy is a requirement of the Agile Mindset in order to “Think as a Customer.”

The context for this is Requirements Management and the audience is the Internal Team.

Usage Considerations

Agile Extension to the BABOK®  Guide – section 7.4

We’ve talked about the strengths, giving voice to motivations and focusing on tasks instead of objects.  Job stories are also great for cause and effect relationships, as well as capturing the intended User Experience.

We’ve not mentioned this, but you don’t have to use just one format for requirements.  You can use Job Stories and User Stories.  Or you could use Wireframes and Models, or other formats. 

However, switching things between multiple formats can cause some confusion.  And try to keep it brief.

Techniques: User Stories

Techniques: User Stories

In this post, we will talk about one of the standard features of many Agile frameworks, the User Story.

User stories are a simple tool to breakdown components and features into small chunks that are understandable, estimable and convey the customer’s requirements to delivery.


Agile Extension to the BABOK®  Guide – section 7.21

Commonly, user stories are represented by a card, with a title representing the activity to be delivered.  This could be a physical card or electronic in some requirements management system such as Version1, Jira, TFS or others.

The format of the User Story identifies who needs this, what is needed and why.

They are a tool for elicitation in that the card does not identify everything there is to know, so this helps engage collaboration among the team. The idea is to describe the desired result, not how it is achieved.

There is acceptance criteria defined for the work produced for each card.  This criteria will have been approved by a representative of the stakeholder or a product owner, and is used to measure results to confirm the work.

User stories are used in conjunction with other techniques we have already discussed, such as those shown above under “User Story Management.” So that shows how central this technique is to agile frameworks.

INVEST Criteria for User Story Readiness

Agile Extension to the BABOK®  Guide – section 7.21

I won’t go into how to write a User Story.  For a discussion on that, there are numerous books.  I’d recommend User Stories Applied: For Agile Software Development by Mike Cohn.  But the Extension does give some guidelines on when a story is ready to be worked.

First, it should Independent or stand alone.  Primarily this goes back to delivering a product that works, and doesn’t need something else.  But I would add there’s a quality of uniqueness to this.  We’re not duplicating work.

Next, it is Negotiable.  The team can determine which is the best way to deliver it.  In other words, the requirement can’t say “Use this product”  We are not designing the product.  We are presenting the requirements, not determining how the requirements are met.  The team does that.

Next is Value.  In week 3 on Value Stream Maps, we talked about how some things do not add value to a process but are necessary.  Sometimes those are regulatory requirements.  Sometimes they are things like a cooling off period.  Although it might not drive profits, there is value in abiding to the regulations.  So, sometimes value needs to be expanded.

Can the team Estimate this.  Do they have enough experience for a frame of reference for their estimation?

Is it Sized Appropriately so that the the team complete this in a cycle.  If not, perhaps it should be broken down more.

Finally, the story should be Testable. There should be enough information to verify that the delivered product works.


Agile Extension to the BABOK®  Guide – section 7.21

Some things to remember about User Stories. These are intended to be the voice of the customer, so the intended results should be easily understood by the customer.

User Stories are one of several varieties of Product Backlog Items, though the others are not as commonly used.

Be sure to review the stories with the customer or their representative to gain approval before beginning work.

Also, remember this is a collaboration tool to ensure that

Usage Considerations

Agile Extension to the BABOK®  Guide – section 7.21

The considerations for User Stories are that they are small, implementable and testable pieces of work.  They are useful in gathering feedback both prior to delivery as well as during demos.

However, they don’t have all the answers, and if you’re not careful, can inflate the backlog.

Also, they tend to be oriented toward what and sometimes misses the why of an item.

Techniques: Real Options

Techniques: Real Options

Real Options focuses decision makers attention on the items that need to be decided now, at the last responsible moment.  By focusing on the appropriate time for making a decision, items which are not needed can be delayed making the decision process much simpler.

Think of it this way, to be agile, we need to have flexibility.  However, the criticism is that with flexibility comes chaos. How can we bring in the latest information and use it for decisions in an orderly way – without disrupting everything we’ve been planning? We need a way to make a decision based on a logical framework, and Real Options is one of the techniques that has been developed to do just that.

It starts with the question, “What is the latest point at which a decision can be made?”  Anything before that means we may have missed important late breaking information.  Anything after that, and the decision is made for us.

In other words, there is a valid reason for Procrastination.


Agile Extension to the BABOK®  Guide – section 7.12

It’s a little different from how we normally think about problems and decisions.

First, An option is only an option if it can expire.  Otherwise there’s never a reason to decide.  So by definition, options have a point where they can expire.  That can be a point in time, or an event that triggers a decision point.  So long as it can expire.

Next, if this option is taken, one or more other options are excluded.  This is a choice of one out of more than one, with one choice winning.  If a competing option is still available after the choice, then it was not paired with the right option.  In other words, it wasn’t understood correctly.

If there’s a “cannot” phrase associated with the option, then it isn’t an option either.  Options are only options if they can be put in place.  If there’s a reason it cannot, then it isn’t an option.

That sounds intuitively true when you think about it.  But we don’t usually think about it that rigorously.

In addition, options must exist within organizational commitments, such as standard tools, acceptance criteria and delivery.

As mentioned, they must have a means or time when they expire, after which the choice is made for you instead of by you.

The earliest option defines the end date for the collection of information in order to maximize the ability to make a decision.


Agile Extension to the BABOK®  Guide – section 7.12

There are 3 statements that are important to remember, highlighted in the Process section here.

  • Options have value
  • Options Expire
  • Never commit early unless you know why And this belongs to the Product Management or Refinement context, directed toward the Internal Team.

Usage Considerations

Agile Extension to the BABOK®  Guide – section 7.12

As we stated at the beginning, Real Options simplifies decision making by allowing the decision-maker to focus on decisions that are needed now, instead of the entire project upfront.  This removes complexity and allows decisions to be prioritized based on events, time, or other constraints.

But it isn’t the most intuitive way to think about decisions, which means – though it simplifies the decision itself, the process supporting this technique is not so simple.

Techniques: Planning Workshop

I’ve heard many people say that Agile is against planning. If you’ve read many of my articles, you’ve probably seen me say something like, “It’s not that planning doesn’t occur in Agile. It’s just done differently.” The question is how.

Instead of laying out every detail upfront and measuring against that plan, Agile plans in chunks as time goes along. And this article is going to talk about how that is done – in the Planning Workshop.

Whether you are using Scrum, DevOps, Lean, or some other flavor of Agile, the Planning Workshop is used to communicate what can be delivered in a time frame.

With a title like Planning Workshop, there might be a tendency to think this is a session for the client. Instead, the goal is to determine what to work on next.


There are 5 elements to the Planning Workshop.

  • Input to the Workshop is an Estimated and Ordered Backlog. 
  • The team velocity, based on previous experience and projected schedules.
  • The goal to be achieved. Often this is an outgrowth of the Ordered Backlog.
  • There is the process of selecting the items from the backlog.  This can include bug fixes, research (Spikes), or any Product Backlog Item.
  • Finally – task planning, where the team breaks down their work and makes individual assignments.

Some important things to note. Most people think of Planning Workshops in the Development Horizon. That’s Sprint Planning, not a Planning Workshop. The Workshops are for the Strategic or Initiative Horizons.

Leading up to the Planning Workshop, no matter which Horizon, the team has estimated the Features in the backlog. 

Also prior to the Planning Workshop, the client or their representative has reviewed the backlog. We know this because it is ordered. This is a session for the Strategy or Initiative teams to decide what can be done in their next cycle, and the results to be communicated with the client.


Planning Workshops are a critical piece to most Agile frameworks.  They are utilized to align initiatives with organizational goals at the strategy horizon or to decide prioritization and sequencing at the Initiative horizon.  Here is where we align features within releases.

Planning workshops determine the intended goal and dates needed, clarifying priorities and details about the features requested.  Once that is understood, the team discusses how to complete the work.

The context is Communications and the Audience is Internal Teams.

Usage Considerations

Some strengths of the Planning Workshop include:

  • Frequent communication
  • Can involve all stakeholders for guidance
  • Because it is focused on a small set of the overall project, it is easier to understand.

Limitations include:

  • The amount of time required to convey a proper understanding
  • How lack of understanding can affect results

Techniques: Kano Analysis

When looking to develop a marketable product, one of the first questions should be how to determine features that will distinguish the product from others. Kano Analysis is how those market movers are found. But more than that, it helps recognize which features are essential to gain customer satisfaction.

The point of Kano Analysis is to determine what will drive market demand in a product.  One thing that is interesting about Kano is that it isn’t a one time thing because the results shift over time.  Like most things in Agile, revisiting previous results can lead you to finding a shift in what drives vs what is expected vs what you should avoid.

Kano Analysis Graph

Here’s the grid for Kano Analysis.  On one axis is the Degree of Achievement.  The other is Customer Satisfaction.  So Kano measures things in 3 attributes:

Kano Attributes

  • Excitement – The more of this you do, the more excited customers get along an exponential curve.  These are the game changers
  • Performance – These are things that go along a linear curve.  People expect to see these attributes.
  • Threshold – These are things that don’t get people excited.  But if you don’t have them, they get disappointed.  Again, it is an exponential curve, but it flattens out as you Achieve it.  These are assumed without mention sometimes, and are absolutely necessary.

Additional Elements

There is a 4th characteristic called “Indifferent” Addressing these would be seen as wasteful.  They might be viewed as a negative – a downward arrow.  Kano doesn’t show these.

To determine which of these 3 dimensions a capability belongs involves a survey. On a 5 point scale 2 questions.  The Functional form question – how do you feel if this is present.  And the Dysfunctional form – How do you feel if it is not present.

The 5 point scale is shown ranging from “I like it that way” to “I dislike it that way.”

The answers are put on a “Kano Analysis Questions Grid” which I’ll show you in a minute.  And from there we can see what builds along the 4 characteristics we mentioned earlier.

Kano Analysis Grid

So if you’ve looked at a sample of several surveys, you will see a pattern on how the respondents like or dislike a feature.  For example, if most of the answers fit into Functional Expect and Dysfunctional Dislike – That would mean this feature is a T – Threshold.

If it is functional Like and dysfunctional Expect – that means they DON’T expect it (it is a dysfunctional expect), but they do Like it.  They’ve not seen this often, but they want it.  These are the big market movers.  If it is a Dysfunctional Neutral or Live With, these are still on the Excitement curve, but perhaps not as strongly.

You can see, this is a very powerful market analysis tool.


Here is the Kano Analysis description.  We’ve covered this pretty well but I want to highlight the Context and Audience.

This is in the Product Management or Refinement context because we will use this technique to determine what to include or exclude from the product, as well as what has the highest priority.

And since the surveys are from External Stakeholders, this can be a great communication tool to find out from them what is desired, and communicate what we are going to address first.

Usage Considerations

One thing to highlight is, this technique is not to be used in a vacuum.  There can be other factors that determine priority.

Another thing is today’s perceptions may shift over time as features become more commonly accepted.  So the phrase “strike while the iron is hot” may be applied to the findings of Kano, meaning act while you can get ahead of the competition.

Techniques: Product Roadmap

The Product Roadmap shows the direction of the product and how the product is intended to grow. It demonstrates alignment to needs and a plan to deliver over time. The Product Roadmap is built around the vision for a solution, it outlines how the vision will be achieved and is defines how to measure progress.


Elements of the Product Roadmap include:

  • The Defined Vision and Strategy – as an input
  • Another input are the Desired Outcomes
  • Maintenance of the roadmap is performed by the Product Management Team, which ensures it is current and remains aligned properly

  • The roadmap will focus on a collection of requirements or themes, or features.
  • And it deals on a high level of things expected to be valuable to the solution.


Above is a simplified example of a Product Roadmap. It shows parallel development of some capabilities, some that are spread across multiple quarters, and some that may be delayed due to a dependency. This example shows that all capabilities are projected to be completed by Q4.


Dealing so closely with vision, it’s no surprise Product Roadmap is used for the Strategy Horizon. It identifies each feature and positions them in columns related to projected timeframes. This makes it a good tool for projecting resource requirements. The context is Product Management or Refinement and the Audience is the internal Team.

Usage Considerations

Product Roadmaps provide a shared focus on what is needed and overall direction, including MVP discussions. It can be utilized for discussions on priorities or other options. Variations can be provided for a target audience.

However, if the vision is chaotic, this tool loses effectiveness. Also, there is a potential to view this as milestones instead of overall directional goals.

And if it’s too detailed, it can be hard to maintain, so keep things at a high level.



Technique: Portfolio Kanban

Portfolio Kanban identifies the status of each initiative, this can be a simple communication tool to give visibility across all initiatives, as well as to monitor and adjust resource allocations.  It is used to give visibility to the Process, Work In Progress, which helps in decision making and feedback on the strategy level.


The Portfolio Kanban will have columns for each step in the organization’s process from idea to completion. Each column has defined criteria for when the item can progress and has limits for entering the column or the work in progress.

The important thing is that each initiative is represented.

Additionally, there are regular meetings to discuss the Portfolio Kanban board and affected prioritization. Metrics are updated to help with prioritization. It is displayed in a place where everyone can see it.


This is a vital tool for the strategy level because it allows decision-makers to have a visual understanding of all initiatives in the organization.  The information displayed can illuminate any bottlenecks and allow for decisions to re-allocate resources.  Also, utilizing Kanban principles, the organization may determine it is beneficial to place constraints or limits in certain cases, which actually increases speed.

The context is Communication and the audience is the Internal Team.

Usage Considerations

Some of the strengths of Portfolio Kanban are that you can set up varieties of this at the Initiative and Delivery horizons., and it allows Portfolio Management to be optimized. It increases feedback and visibility into what is in progress and where the bottlenecks are.

Some limitations are that it is a bit one size fits all at the strategy level – so if there are different paths for some initiatives, this would not work well for them.

And it doesn’t explain why an initiative is in one place or phase for an extended period, just shows that it is.

Techniques: Minimal Viable Product

Because of the title, many people are confused about Minimal Viable Product.

This isn’t the same as just getting by.  For example, if a new internal project is underway, the organization was already “getting by” previously. But the new MVP project provides essential coverage to meet a need without expensive “gold plating.”  If funding ran out and MVP was achieved, you would have a working product in the market or for your internal client and would be doing much better than before.  Additional features may be developed beyond MVP, but those are done after the product is viable. So, just because MVP is achieved does not mean the project will stop, just that it could and still be usable.

That is an important threshold to cross in product development.


MVP is an important technique for Avoiding Waste.  When a potential capability or feature is added to the solution, one of the first things we should ask is whether this is necessary for a product to be viable.

And by viable, that means that it meets the minimum requirements for the early adopters of the solution.

Again, it isn’t that non MVP features will never get done.  Just that the MVP features will come first. In other words, it avoids waste by giving priority to what is necessary.


In defining the MVP, it is important to address the following.

First, identify who needs or wants this solution.  Then from that group, identify the early adopters.

Next, identify what needs to happen for the goal to be met and how you can verify that has been met.

Thirdly, as the solution goes along, actually measure the results to verify the intended need is being met by the minimum solution.

Finally, Define the requirements for each feature of the MVP solution.


One interesting thing about MVP is how this focuses on early adopters.  If you do not satisfy them, you do not have a product.

Another aspect is this is not a static state – MVP can change over time.  As new features are identified, it becomes important to understand whether these are to become part of the MVP or whether they should be delayed for later – risking their exclusion from the product if there is not enough value.

That determination is how waste is avoided with this technique.

The context is Product Management or Refinement and the Audience is both Internal Teams and External Stakeholders.

Strengths and Limitations

Some of the things to be aware of for MVP Using are how it can be used to avoid unneeded or unwanted robust features.

Also, it’s important to realize the amount of research required to identify what is important for early adopters, and that sometimes features may be a best guess.  And if the solution is simple, going through all this might be overkill.



It has been a while since I’ve written, and this post will be a little different from normal. Today I’m going to talk about sacrifice.
Thirty months ago this very week, I went into the hospital with severe pain. I’ve written about the experience previously in my post “The Will to Overcome All Obstacles.” And I’m not going to retell the whole story here, but mention a detail I had left out previously. The detail – thirst.
The kind of thirst you have while suffering from pancreatitis is like nothing I’ve ever experienced. I had 6 different IV bags, two of which were saline, going at the same time, so my body couldn’t have been needing fluids. In fact, in a short time, they put about 30 pounds of fluid in me. Still, the thirst was unbearable.
I was not allowed anything orally. I finally got permission to have 2 or 3 ice chips. They lasted a few seconds and I did my best to savor them. But within 2 minutes, the effects were completely gone. I could barely talk because my tongue was sticking to the roof of my mouth.
I don’t know why the subject of thirst came to mind this evening. As I was thinking of my experience, I remembered an old TV show called “Family Affair.” One episode had the oldest sibling trying her first job in a hospital as a nurses aide. Walking past a patient’s room, she heard cries for help. “Please give me some water. They won’t give me any water and I’m dying of thirst.” Sissy gave in, and when the medical staff found out, she was told she couldn’t work there any more.
I know that thirst that the patient had.
Another thought came to mind tonight. In the Old Testament book of Psalms, there are the lyrics to many ancient hymns. Many are written by King David or King Solomon. One in particular is unique, because it gives the gruesome details for a kind of death that the Romans would invent hundreds of years later.
Psalm 22 was written by David. But it’s really about events that would happen to one of his descendants, Jesus. When you read this Psalm, it is almost as if David is recalling the experience of a crucifixion – again hundreds of years before the Romans were in power. It’s an amazing passage.
Vs 15 says:

My strength is dried up like a potsherd, and my tongue sticks to the roof of my mouth, you lay me in the dust of death.

Just before or after this verse, it talks about how people gloat over him. How they gambled for his cloak. How his hands and feet were pierced. All of his limbs were out of joint. All of this would happen in the New Testament as recorded in the gospels.

I can imagine that kind of thirst. I can’t imagine the rest of it. Even reading Psalm 22, and being acquainted with pain, and wondering if I was going to make it – there’s a long way between what I had and what He did.

I know this is hard for many to understand. For Him, what He did was a sacrifice. He was the offering. Others thought they took His life. He laid down his life. Willingly.
Theologians say that Jesus came to experience the kinds of trials that man faces and to overcome them. By doing that, his perfection could pay for our evil.
If that is true, His measure of our worth is much greater than we can imagine.

Today, as this is published is a day celebrating sacrifice – that of Veterans.
I don’t know how people willingly offer their bodies for this nation, our ideals, these people. I don’t know how and, as a civilian, it’s hard to comprehend why. It’s not that I don’t love my country. It’s that this kind of sacrifice goes beyond any reasoning.
So, today, Veteran’s Day, take the time to acknowledge their sacrifice.

How I Became a Salesforce Business Analyst

How I Became a Salesforce Business Analyst

Well, this is my 4th “How I Became …” article. Of all the articles I’ve written, these have been the most popular. Letting people know your path helps others envision how they can do it too, and that the course is NEVER perfect. It resonates. And I enjoy poking a bit of fun at myself while relating those Non-Perfections.

I could say that first, I became a Business Analyst, then I became a Salesforce Administrator. Combining the two and BAM – I’m a Salesforce Business Analyst. But if you’ve read the previous three “How I Became” posts, you know the story is a bit more interesting than that.

And Now – The Rest of the Story

This story could be subtitled “The Art of the Pivot.” There are so many re-directions.

Frankly, I have become a bit frustrated with Business Analysis in my geographic area. I love the job, but it seems to have stagnated, or perhaps the market was saturated here. For whatever reason, I have not and I do not know any Business Analysts in this area that have experienced sustained financial growth. In actuality, most have been flat for several years. Something had to change. But what?

I had just wrapped up a stint with the Transportation Cabinet in October 2019, a terrible time to begin a job search. With it being the end of the year and with Holidays around the corner, no one was in a hiring mood. But I didn’t know how terrible it was going to be.

Too much time on my hands.

So in December, I was just about to catch up on my favorite podcast, ChooseFI. The guest was Bradley Rice, and the topic was “The Case for Part-Time.” Bradley was sharing his story about making more than full time pay as a part-time Salesforce freelancer. I’ve talked about that previously here. With my free time, I decided it was time to investigate. And if I’m going to try something different, it needed to be a game-changer.

With that as an introduction, and if you’re not familiar with Salesforce, let me back up a bit. Salesforce is a platform that hosts enterprise-level software for businesses. It is not an MLM. Some people see the word Sales, and hear the enthusiasm of those in the “Salesforce Ecosystem” and think there must be something up. No pyramids. No cold calls. It’s Information Technology.

Bradley’s interview gave me enough breadcrumbs to investigate. Go to, sign up for fully functional training environments for free, take online courses on how to do everything for free, then get certified and apply for jobs. The only cost is for the exam at $200.00.

Giving your career a boost for the cost of about 2-3 months’ work and $200.00 – that’s a great deal.

So, in January and February, I was still applying for traditional Business Analyst jobs and was going deep in the interview process. But all of them were about 80 minutes away. And each was wanting that one specific technology, and I never had it. Nevermind that Business Analysts are on the requirements side – it’s the developers that need the technology. I’ve even heard feedback from interviewers saying, “Our hiring manager is crazy for not hiring you. You can learn this in a week.” Still, that was keeping me from winning.

And in this case, winning would have meant a job with wages the same as 5-8 years ago, driving 80 minutes each way to a city that was soon to be in the news way too much.

Every Rejection was a Confirmation

I continued pursuing certification. I knew I had to do this. In February 2020, I sat for the Salesforce Certified Administrator exam and passed.

Oh, but we all know what happened next, don’t we?


Yep, the COVID-19 pandemic shut virtually everything down. And I realized I needed to double down on things.

First, now that I am newly certified, I needed to expand my network to a whole new audience. It was an audience that wouldn’t have heard me without the credential – I couldn’t start sooner. My LinkedIn profile got an overhaul. Then I reviewed it with Bradley and overhauled it again. Branding is a huge deal, and I was changing my brand.

Next, I realized that one certification was going to get lost now that many more people are entering the job market. And many of those had experience that I didn’t have.

How do I leverage what I DO have?

Another LinkedIn overhaul.

Revise my job target strategy.

Create a new set of Resumes.

Get my name on Salesforce Communities and network there too. That’s a whole new world to explore.

What other certification can I get quickly? Oh – one of the credentials is called Platform App Builder. This is 70% covered by the first certification but deals more with – well – building apps on the Salesforce platform.

Backing up again. I had mentioned that Salesforce is a platform. It does have several core sets of products, such as Sales Cloud, Marketing Cloud, Service Cloud, Non-Profit Success Pack, and others. However, Salesforce was the inventor of the app store, called App Exchange. Third-party applications can be built and purchased there. Also, custom applications for an organization can be built to run in a Salesforce environment (or Org). So, building apps is what the Platform App Builder is all about.

And when I say Building and app, I most likely do not mean coding. Salesforce has native tools allowing for the production of sophisticated applications without writing code. And of course, if you need something beyond those capabilities, you can write code. I would explain how that works, but I had to study it for five months to understand it myself fully.

It has been a great surprise how much you can do in a low code model.

Back to our story

In March and April, I continued building my network in the Salesforce ecosystem and pursuing the next certification. I got the Platform App Builder in April 2020.

Overhaul my LinkedIn profile again. Change the messaging a bit.

What about those Salesforce Communities? Oh – there’s one for job postings. I better make sure to get on that. And there’s Admin and Local groups.

Keep networking.

With the new competition, I need to get some experience. But how?

Bradforce and T.E.A.M 4 Travis

I contacted Bradley, who at this point was hitting a stride in helping people like me, and got some feedback about how to volunteer for organizations to gain experience through the Non-Profit Success Pack. NPSP is offered at a considerable discount to Non-Profits. With Bradley’s help, I was able to sign up through Taproot to help a brand new Non-Profit get started using Salesforce.

T.E.A.M 4 Travis was started to raise funding to help identify children that have Asplenia, a rare and often undetected disease where the spleen is either missing or non-functional. Travis was an energetic four-year-old who, after catching a typical childhood illness, died because his immune system couldn’t fight it off.

So, now I’m getting some experience. Is it enough yet? I don’t think so. And the job market confirms it as COVID-19 rolls along.

What can I do to get attention? I haven’t done anything on video. Is that a possibility?

What is my Strength?

My strong point is Business Analysis. After all, I’ve been doing it for over a decade. Can I do something on video there?

Sure I can.

In the previous summer, I had developed a course for Agile Analysis Certification (AAC) through IIBA. I taught myself how to create videos and turned the AAC class into a self-paced course, and submitted it to Udemy. The process wasn’t pretty. It took about 40 hours to produce 3.5 hours of video.

Is it a rip-roaring success?

Yes. Well, in my opinion, the only opinion that counts, the course has accomplished precisely what I had hoped. Although the original “Virtual Classroom” version had about 65 students, the Udemy version has to date has this many students – three.

And two of them were given a free pass for helping me out while I was learning to do videos. The other – half off.

Honestly, I wasn’t doing this to be a huge hit. I viewed it as the kind of thing that can help later, whether anyone buys the course or not. We’ll see if it does.

Sell Out

More networking. LinkedIn overhaul. Remove ancient jobs. Better focus.

Then it hit me. I need to acknowledge what I’ve been doing with these odd items that have not paid more than $40. The course and TEAM 4 Travis were hidden. I needed to sell my experience toward Salesforce. Instead of just saying I have certifications, who am I now? And how can I promote that?

Then I understood something Bradley had been saying all along. I needed everything to scream Salesforce. Until then, no one believes me because I did not think it myself.

Salesforce Consultant

If I don’t believe that, as a Business Analyst, I am already a consultant and that with my recent experience, I can go a long way with Salesforce, then I’m certainly not going to convince anyone else. Perhaps my biggest lesson is never to let myself believe the voice saying “impostor” instead of the voice saying, “just do it.”

I mean, I have set out to do so much – two certifications, learning to video and producing over 3 hours of self-paced content, starting a new organization on Salesforce – and yet I still did not believe in myself. The unbelief was showing by how reliant I was on Business Analysis instead of Salesforce.

So what do I want for my career after all of this, and how do I communicate that?

Clarifying Goals

Be sure that I’ve had goals for this process all along. But those goals needed to be clarified and take root in my resume and LinkedIn profile. They needed to be a reflection of who I am and what I want.

I came up with this.

“Sr. Salesforce Consultant and Business Analyst with a passion for the elimination of Technical Debt and Process Redesign on the world’s best SaaS CRM platform.”

Sr Salesforce Consultant? Yes – I began listing my Salesforce accomplishments under the umbrella of a Sole Proprietorship company “Applied Agile Analysis,” which is the name of a blog I started well over a year before. That’s not the most appropriate name for the company trying to transition to Salesforce, but that is an advantage. No one knows I’m the only employee. The name reflects my Agile Analysis background. I had a lot of material under that name. And if I say I’m the Senior Salesforce Consultant in a company that focuses on Agile – maybe there are other consultants with a different emphasis. Plus, I am the most senior member of the (one person) staff.

Imposter syndrome – conquered. I’m selling what employers need to hear from me now. I can deliver the goods, but only if given a chance. The title removes the barrier.

But if anyone questions, what do I show them?

Shhh! Don’t tell my wife

OK, I have CBAP, AAC, PSM-1, SCA, and SCPAB certifications. My wife has forbidden me from getting any others this year. And to date, I haven’t. But I have prepared.

Several recruiters have pointed to one of the Salesforce Consultant certifications as the Magic Elixir I am missing to hold their attention. So now, I have completed the trailhead courses for Sales Cloud and am 75% through the Focus on Force training.

And while doing that, more networking.

And out of the blue comes an email from one of the Salesforce communities. It’s the one where I posted that I need a job about six weeks earlier.

Development Consulting Partners

Dorian Earl saw my post and contacted me about freelancing. He has formed a company of freelancers and was winning significant projects. His team includes Administrators, Developers, Consultants, and Architects, and it had just been awarded Partner status with Salesforce.

My first project is a software company catering to education. They have only budgeted 5 hours per week. But over time, I can string together several of these projects, each time demonstrating increasing capabilities and without worrying about losing that one big job again.

This is exactly what Bradley had been talking about as a goal. How Dorian was doing it was a little different.

My client had over 15,000 leads, and they were severely duplicated. We installed a system to help clean up and prevent future problems.

Finally some Momentum – Liberty IT Solutions

I had barely been on that job a week when I got a LinkedIn message about another opportunity. This one, I could tell, was serious. They wanted to talk to me today. Then HR would line up an interview with the director tomorrow, and the HR person would follow up immediately after that.

Now for the comedy portion of our show

The interview with Liberty was scheduled for a Thursday morning. The night before, I drove to visit family. And by family, I mean family that just got a new dog – a rescue – one that we think had been abused.

Leo is a 9 lb Yorkshire, with a bad attitude. He doesn’t trust anybody. I spent the night trying every doggy treat known to man, only to be met with growls and snarls and barks.

Thursday morning, I’m getting ready, and Leo comes after me as fast and hard as he can. He was going to bite, and I barely got my door shut before he face-planted. Ten minutes later, I left the room to set up for the interview and – repeat.

At nine pounds, Leo is no threat. But tell him that. And it is my mom’s dog. And there’re laws against retaliation, not that I’d ever hurt the little guy. Mom – I can’t have Leo acting like that during my interview. So she takes him to the van and sits with him in the driveway during the interview.

Nerves calming, let’s start the meeting link. Oh – it’s Microsoft Teams. That is the one conference service that I’ve never been able to get to work consistently. And the streak doesn’t end today.

My video conference became audio only on my cell phone. Which means I can walk around, and no one knows that I’m not sitting still. I’m more comfortable because I’m the ultimate pacer.

The company is looking for a Business Analyst with Salesforce experience. They were dealing with duplications – and guess what? I’m working on a bunch of duplications right now. They want someone who can mentor others – and guess what? I just developed a course training Business Analyst that has been presented in virtual classrooms as well as self-paced formats.

I told you that would be helpful. But there’s more.
I have previously shared about my survival of a major medical event in 2018. The results of a botched out-patient surgery has given me some of those pre-existing conditions which are so dangerous in this COVID era. Because of that, remote work was a virtual (pun intended) requirement. And this job offered it.

Everything was clicking. Plus, Liberty serves Veterans Affairs. This isn’t just a job for a corporation. This is helping those who fought for our freedoms.

In spite of the events – It All Worked Out

That afternoon, the HR representative texted that the company is extending an offer.

A trail that involved year-end hiring freezes, career pivots, pandemics, more career pivots, working for free, study, learning tons of new skills, prayers, tears, frustration, hopes, and hopes deferred – has finally ended with hopes fulfilled.