About April Fool's

I'm intentionally not following what everyone else might be doing for April Fool's day, though I suspect many are focusing on a bit of levity amid the current global situation. If you're finding this post out of context, look up "news in 2020."

I will instead write a few thoughts on what has helped me sell a plausible practical joke while keeping it in good fun.

First of all, make the topic relevant and something that others might expect you to do. My past April Fool's post included:

I think these were mildly successful (one colleague flattered me by saying he thought the Lisp mediator was real!) because I've previously shared examples, good practices, and "fun" posts. These also followed a few trends popular at the time such as custom templating frameworks, "headless" CMS before the term became popular, and augmented reality interfaces.

After looking at plausibility for both the topic itself and whether you might post about it, I then try to avoid humor at the expense of individuals. I have been able to What seems to work well if you can joke along with a community you're a part of, in a way that either celebrates admirable aspects of your colleagues or is so silly no one should take offense.

See some of my posts that I've labeled under "humor." You can determine if they're actually funny, but most should be good-natured posts, appreciating community member contributions.

Apologies for the times I may have crossed the line. I believe I've fixed any particular issues, but feel free to let me know and I'll gladly fix, remove, or otherwise update any of those posts. One lesson I've learned is you don't know how things will be received until you actually start publishing. Community norms and expectations grow and evolve over time. It's good to follow, but it can take some practice to find your way in a given environment or community. 

Finally, and the main reason to avoid an April Fool's joke today, is I try to avoid topics that if taken seriously, could be misinterpreted or disappoint people. This is where it's good to avoid crying wolf on topics about negative or even positive results, expected deadlines, or unrealistic promises.

Being in a product role, I'm careful to avoid jokes about features, deadlines, or user feedback unless the context is quite clear. And even then, it's good to separate perhaps a valid observation (e.g. "customers keep asking for features that we have!") from the just-as-valid requests (e.g. they're asking because the existing features aren't clear).

In summary, I think I've done okay joking in a somewhat professional context by trying to be respectful while using plausible, yet sensitive topics. Stay safe, thanks for reading, and use humor as needed. We probably need a bit of fun for a while longer.

Yet Another Post Pondering Business Analyst vs. Product Managers

You may have heard there are many paths to product ownership or product management. I'd like to help encourage people interested in product roles by sharing some of my own observations in my own journey into product management. This post ponders titles and roles, the overlap between responsibilities across various jobs, a nod to Maslow's Hierarchy of Needs, and a reminder that evolution is not a ladder.

I'm most familiar with the version of the business analyst (BA) that bridges the "gap" between the business and development teams. In internal and external roles as a business analyst, I would be responsible for discovering and documenting anything from business problems to detailed user stories and the eventual requirements for the technical solution.


My own journey started as a Web development intern with a side responsibility for research. That evolved into an "internet research associate" position focused on all kinds of research.

As an example prompt, I would research and evaluate competitors and internally share a summary of their products and services. I've investigated health-related technologies such as heart rate monitors or fitness trackers at a time before they became mainstream. Web accessibility and other compliance topics would come up. The prompt that shifted my career path was a search for "a CMS that didn't take over your websites."

That led to questions to various vendors, demos, and the eventual selection of SDL Tridion (Sites) to manage around a dozen websites covering both public websites and a partner extranet. To help understand and implement the solution, I was offered and accepted a “Web Business Analyst” role.

At the time, I assumed the next step for a BA would be something like Project Manager or some kind of "leader of teams." In some ways, I would eventually be right, but not in the ways I imagined.

A Proliferation of Titles and Roles

First of all, my company had different departments, some of which had their own BA roles, independent of my group. So the expectations, meetings, and career paths for people with similar titles in the same company don't necessarily align.

I've seen these differences come from product, department, or location. I've also learned to not worry about such inconsistencies. As an employee in a large enough organization, you might ask and encourage the company to align, but roles and people change. Focus on the problems you're solving, help and encourage those with similar problems, and go from there.

In a broader sense, I have also seen an overlap between user experience (UX) activities and those that have traditionally fallen under business analysis. Similarly, there is an overlap between Product Manager and Product Owner roles and responsibilities. For a good comparison, see Melissa Perri's distinction that "Product Owner is a role you play on a Scrum team. Product Manager is the job.".

If I were to suggest some hypothetical expectations of a few information technology roles, it might look something like this.

This is just an example to suggest product-related roles may work more across the business and deal with customers more than user experience and business analyst roles. The actual mix of skills and expectations will vary by company, title, and your own contribution to a given role.

This post by Brian de Haff on this blog post for Aha! suggests similar differences in that product managers are a bit more outward-facing than business analysts, whereas BAs focus more on technical specifications rather than business requirements.

In practice, across the projects I've run, these aren't rules but rather guidelines. As a software consultant in a BA role, I've had to work with stakeholders and work with customers. Conversely, now as a product owner, I will still address technical specifications when needed.

Hierarchy of Roles and Team Members: Basics First

I see titles and roles split based on how the industry has evolved as well as the size of organizations.

For small organizations or start-ups, you might start with a few “do-it-all” engineers. Go back a decade or so and all web-related activities fell under "webmaster."

When an organization is big enough for more of a cross-functional team, you might start adding roles to get to the following roles within a team.
  • Product Manager or Product Owner
  • Designer
  • Engineer
  • Quality Assurance
As an organization scales up, they will add more teams, possibly mixing in more roles for cross-functional and multidisciplinary teams. This might progress, in an order such as:
  1. Just engineers
  2. Engineers plus quality assurance, QA
  3. Engineers, QA, plus a part-to-full-time Scrum Maser
  4. Etc.
We can visualize this kind of hierarchy of team needs with something like this, where it makes sense to fill out roles in the bottom before adding more on top.

The point here isn't to suggest a hierarchy of importance, but rather that it doesn't make sense to add testers if there is no code. Nor do you need more processes and connections to the business if there isn't much of a team. 

To grow this out, we might have more granular roles such as the following, though not necessarily all within the same team:
  • Product Manager
  • Product Owner
  • Scrum Master
  • User Experience (UX) Researcher
  • User Experience (UX) Designer
  • Front-end Engineer
  • Back-end Engineer
  • Quality Assurance (QA) focused on functional testing
  • Quality Assurance focused on automated testing
A more internally-focused team might have a BA instead of a designer. And a large-enough organization might have both. Many teams I’ve worked with have people with a range of skills as “hybrid” team members with a particular specialty, but a broad understanding of technology as individuals with “T-shaped” skills.

When in doubt, I've learned to always start with good, solid engineers. A mix of backgrounds and experience is good and I prefer enthusiasm and attitude over experience. If you don't have enough engineers, the QA manager might not let you have more QA engineers. :-) Without proper testing, then the pressure for comprehensive, prescriptive requirements upfront increases while it gets harder to identify edge cases and issues during design and build phases.

I've seen QA also work well as a path to product roles. By understanding how something works and asking "why" enough times, the curious and inquisitive will eventually end up at the customer.

Finally, as the industry recognizes that good UX design can and should also be applied to internal systems, I expect the blur between UX and BA would increase.


Let me be clear that similar to evolutionary theory, stages in career development is not a ladder. Over a decade ago I had the misguided notion that certain roles were the next natural step after other, more junior roles.

In this post by Laura Brandenburg, she concludes that the BA role could be an interim step to Product Management (PM), to which I agree. Similarly, Kevin Brennan suggests product management might be a good fit for a BA interested in executing their own vision.

However, it's not the only path for a BA, who might continue in an analysis role, work as an external resource as a consultant, or perhaps move into a management role. Personally, I went into cross-functional Project Management and then Project Management within IT operations before I realized I enjoyed working with customers slightly more than vendors. Ultimately, your own path will depend on your interests, aptitude, and opportunities while you might adjust the dimensions mentioned above to focus more or less on working with stakeholders, requirements, specifications, or customers.

You might also opt between a more individual contributor versus a more managerial or leadership role. There are developers, leads, and subject matter experts who have years of experience in their respective roles as invaluable team members. You might opt to fight Peter's Principle and find the role or work you love, without worrying about the specific title. Though when in doubt and to keep things interesting, find a way to grow years of experience rather than the same year, several times.

Headless Does Not Mean Page-less

I've heard confusion over pages, (modular) content, and "dynamic" content for as long as I've worked with content management.

To revisit the topic, I want to be clear that "headless" does not mean page-less. There is a legitimate and quite familiar use case for "dynamic content" without pages, but we shouldn't ignore some critical points about content management, human perception, and the nature of the internet or specifically the World Wide Web.

Stuff I've Learned About Product Management

Nearing four years into product roles for "enterprise product management," I've learned a few practical lessons that the product, UX, or leadership books, websites, and podcasts seem to gloss over or assume.

Specifically, remembering your audience creates a strong pressure on your communication skills. Roadmaps expire and you'll recreate them over and over again. And you have to be willing to break the "rules."