Skip to main content

Author: Mike Lenz

You Don’t Know Jack

Written by Mike Lenz on . Posted in Articles. 1 Comment on You Don’t Know Jack

lenz feb10A healthy respect for the magnitude of what we don’t know

Every time I start to believe I’m building an expertise in something or starting to mature into an experienced “adult”, life has a way of smacking me in the head and reminding me that “I don’t know jack.”

In general, the word “expert” has always stuck out to me. What does that word mean? I’ve always thought of it as “you know everything”. So for me, to be an expert on something is an insane achievement. You know everything? That’s crazy.

I have a hard time even imagining the reality of knowing everything about something. Under that definition, I’m not even close to an expert on anything. Often when browsing Twitter I’m exposed to so many new ideas, new topics, new thoughts that the sheer volume of shit I don’t know can be overwhelming. Even a single topic. Pick one thing. Can you know everything about even that single topic? I don’t know.

But we don’t need to know everything to contribute. Each of us as individuals adds our own unique value from the perspective of our own unique set of knowledge. No one else on the planet has the exact same combination of experience and knowledge, and the pursuit of improving that collection is called Life.

In my opinion, more important than the depth of a person’s knowledge is their self-awareness of what they don’t know. Am I an expert on Digital Marketing Platforms, Content Management Systems, or Adobe Experience Manager implementations? I wouldn’t use the word “expert”.

However, I would happily match myself up against anyone else in terms of ability to lead and execute an enterprise digital marketing platform implementation. I have depth of experience and knowledge on the topic, but more importantly I know what I don’t know. I approach each new engagement with a healthy curiosity and eagerness to find new challenging problems to solve.

The reality that there’s so much still to learn is what makes each day so exciting. So yes, I don’t know shit and neither do you, but that’s what makes life worth living.

So let’s learn something today and remain humble to the reality that there’s always so much more left to learn tomorrow.

Don’t forget to leave your comments below.

Good Business Analyst, Bad Business Analyst

Written by Mike Lenz on . Posted in Articles. 1 Comment on Good Business Analyst, Bad Business Analyst

Lenz Aug18A Good BA has a product management approach to their role, partnering with stakeholders to define the very best solution. A Good BA is the subject matter expert of the project requirements. They are viewed by both Creative and Tech teams as one of their own while in reality serving neither, only the client’s project goals. A Good BA has patience to learn from the client, educate the client, and push back when needed.

A Bad BA acts as a note taker, documenting what other people tell them with no vested interest in the quality of the product being built. A Bad BA is a gofer and assistant for the tech team. They document just enough for client sign off.

A Good BA pushes decisions and detailed design understanding early. They focus clients away from bells & whistles and back onto solutions that drive project goals, and when necessary are not afraid to remind the client of agreed upon scope. A Good BA communicates as well in written form as they do verbally. They create great requirements documentation that tells the story of the product. Their documents flow in a logical way from feature to feature, big idea to detailed specifications. A Bad BA is distracted by other people’s jobs (user experience or tech solutions) losing focus on their own (documenting the What).

A Good BA ensures all sections of their documents add value. They flush out and define detailed requirements organized and aligned to business goals and scope. A Bad BA fills out a template. They write down disjointed meeting notes from stakeholder interviews and call them requirements.

A Good BA defines accretive requirements. A Bad BA uses words like may, shall, and should. A Good BA includes notes and supporting information in their documents for increased reader understanding. A Bad BA does the bare minimum, forcing conference calls to explain written requirements.

A Good BA is organized and manages open item trackers for their documents. They can accurately communicate work remaining and blockers to closure. They anticipate design challenges and drive clarity through their requirements. A Bad BA lets the tech team do their work for them by flushing detail through tech design questions.

A Good BA partners with the Client to ensure they are prepared for User Acceptance Testing. They ensure the client understands what was documented and categorizes appropriate UAT defects as Change Requests. A Bad BA assumes the client is organized and prepared. They flood the tech team with duplicate, unclear, and as-designed defects

A Good BA is viewed as a critical member of the team’s success. They do their best regardless of whether or not someone is going to read the document. A Bad BA cuts corners and is a replaceable with well-annotated wireframes.

Don’t forget to leave your comments below.