A blog on content management and digital experiences
New Year. New Role.
After a crazy 2020 and my family's move back from the Netherlands to the US, I'm ready to start a new role as a business architect within SDL Professional Services in our NASA division (that's North America / South America and not, well, NASA) .
Crossroads are overrated
SDL Tridion Sites 9.5 is released! Read the announcement on SDL Community.
Having moved back from the Netherlands to the US, this will be a long post as I reminisce my earliest moments with Tridion Sites, thank my team in a GDPR-friendly way, and ask you one more time to keep working with the product and development team to continue improving my favorite product.
Memory lane
I still remember asking our implementer (the same guy who coined the term, “The Fifth Tridion Environment,” what was the difference between embedded fields and a link. A few weeks ago we shared drinks one more time in a COVID-19 socially distanced outdoor venue, not far from the SDL Amsterdam office, which is still awaiting to open following company and government guidelines.
Back around 2008 or 2009, I recall how I fell in love with content modeling when a developer asked, “wait, how will the editor enter the markup needed for the page?” That’s the beauty of it. They don’t.
I remember explaining where to put Web Page metadata into the CMS and reminding my former colleague from the Bronx with the great demeanor and cool accent to check-in that Schema and be sure to associate any Templates needed to it.
And I was right when I said that commit error message meant there was a duplicate binary. Yeah, I knew "my" system.
The Classic UI is polished and nuanced
Yet, I’ve been humbled several times over when I realized how much I assumed I knew to only to (re)discover icons for BluePrinting actions in Tridion Sites. Favorites in the item selector showed organizational items rather than everything, at least until the new UI. An item in use in older items doesn’t actually prevent deletion most of the time, with an exception for when you attempt to delete Schemas). If you try very carefully, you can intentionally break a reference. That's a trade secret. I won’t say how.
Oh and apparently you can choose to create a Multimedia Component even a folder has a default regular Schema set. And in the Schema drop-down you'll get both the regular Schema set, pulse the available Multimedia schemas.
Up to right before the release, I’m hearing a refreshingly different kind of response after a few years of making new UI-related features, but not much changes to the basic experience of creating and editing content. Rather than suggesting all the improvements we've now added into the product, people are noticing what’s not there (yet).
I’m confident to say paradoxically yes, this release is going to be refreshingly welcome and different while many will want more.
My main job
My job as product owner wasn't to put a decade of my experience with the product into the product. That was a happy coincidence and motivation to improve the product.
My job has been to bring some of our best, experienced, newest, brightest, and occasionally stubborn (in the right way) people you’d ever love to work with to prototype, research, build, test, and validate improvements to the product and specifically the editorial experience.
Yes, we needed a new editorial experience and the technology to support it. Our ahead-of-its time custom HTML and JavaScript framework was still amazingly flexible, but required, well HTML, JavaScript, and vendor-specific skills when frontend expertise has moved into frameworks such as React, Vue, and Angular.
Everything you would assume is easy was likely harder than you could imagine. We never (rarely) debated on button color. But we could spend some time considering placement, language, and order; you do not want to hear about the dozen iterations of what “back” means, where it should go, and what icon to use.
I won't detail the lengthy discussion about the word, "screen." While I recognize the nuance, I stand by my choice to drop the word from "View in explorer." :-)
The team
But these are minor inconveniences compared to how the team brought their best talents to the mission. I have one dev who really considers what editors needed keeping in mind what issues have come up before. He’ll mock up working prototypes with a bit of HTML and JavaScript and kept our (my) ambitions in check, reminding us to focus on the mission at hand.
I have another who both loves tools and abstraction, yet is willing to do the dirty work, unit tests, and gnarly bugs I have a hard time understanding let alone explaining. I bet no one (except perhaps this guy) could explain how Favorites in the item selector should actually work. With BluePrinting. But my dev likes those kinds of challenges. Coincidentally he also likes pushups.
I have a QA engineer who joined and immediately found bugs in third-party components that have since been fixed. You're welcome, un-named third-party component. Oh and he programs video games for fun.
I have a QA lead who has a keen sense of how stable something is at a given moment, aware of when requirements need to be adjusted, and who, when finished building one of my LEGO “morale” projects, asked why there were "leftover" pieces. Note: it's a standard LEGO practice to leave a few extra pieces in a set, but it's a nice reflection on the care in the statement, "but Alvin, there are extra pieces in the bag. Is this to be expected?"
I had a designer start with an early initial assignment to design a "better date picker," who has since grown to design the new page and multimedia experiences. Alongside him, we brought on other UXers more familiar with other SDL products to then bring the SDL Graphene design system to Tridion Sites and then interactions in Sites back to products like Docs.
And I have a researcher who reinvigorated our customer and UX research program which now includes “days in the life of” sessions, usability tests, customer workgroups, customer journey workshops, and our latest, an early access program supported by management, the System Team, and Community.
Joiners, leavers, and rejoiners
Over the two-year project, we had people leave, go, and at least one to return. The hidden catch with modernizing an element of your system is the popularity with the given technology.
We had one dev who would respond to work with either a "yeah, sure," or "you sure?" He would fearlessly build something on requirements as simple as, “you know, like when you add an attachment.”
"Done."
Oh wait, that’s supposed to have some filtering.
"Okay. Parameterized."
We had another team member kick off the project and get us to a good spot, even making a debut as a technical conference speaker. Though he's working on other things, he'll still take the time to answer a question on Tridion Stack Exchange.
And along the way, we had some jump in on shorter contracts and others that have returned. Each saw the mission, did what was needed, and we’re now close to the finish line.
Through most of the project, we had an amazing guide, guru, and friend who not only built a good amount of the experience and supported multiple teams in multiple UI projects, he would even create break down interaction designs when needed to answer a question, challenged us to be better than we thought we could, and still gathered people together after hours for drinks to relax and welcome joiners or thank leavers.
Oh and thanks very much for arranging the photography session parting gift. Here is one of the wonderful photos of our family.
Thanks to Florencia Jadia for the wonderful photos!
One last project
I first had a chance to work with product management and development a few years back but in professional services as one of the stakeholders. That was until KnewKnow got me to Amsterdam as a Technical Product Manager. I eventually moved into a proper Product Owner to focus on integrations and then the new UI for Tridion Sites.
So my family's "2-3 year" stay in the Netherlands became, “at least until we ship the new UI.”
The company's mission was a new editorial experience. My personal mission was to make sure this team was more than prepared to do this without me.
Though the project officially kicked off early in 2018, before that we recognized a challenge with getting the recently-introduced notification API to work nicely with the publishing queue. I actually had to fail a story that automatically updated the Publishing queue because it didn't react fast enough to changes. Though Anguilla was built a decade ago for extensibility and a proper separation of concerns, it was originally created back when polling was perhaps a more standard practice. This was a bit before "one-way data binding" and more modern approaches my devs tell me about.
In 2018, we started with a small team to quickly set up a prototyped back-end, compliments of one of the architects at the time, to quickly enable us to set up a new front end. We needed to confirm we could get an end-to-end setup with a REST API and React front end. We didn't know how fast and far we would get but knew we had to focus on the editor's experience, which is something that isn't as visible in our online community compared to technical topics.
For example, in the rich text editing survey from a while back, editors specifically favored features like full-screen editing and clean paste from Word, which didn't show up as strongly in survey results from technical users.
Assuming it was smaller than the entire content manager explorer, we started with just Experience Manager. This was the in-context editing UI that many customers have seen but didn't always have the right setup or time to take advantage of. But with the setup more out-of-the-box in more recent projects, customers were finally starting to use it and request improvements in usability or performance.
But as soon as we (especially architect Likhan) saw that we already had an item selector, a list view of items, and the ability to edit content, we had a choice. We could stick with the plan, release yet another UI update to SDL Tridion Sites alongside the existing UIs. Or we... could pivot and focus on the main editorial experience, the CME. So mid-project we chose to instead focus on the Content Manager Explorer.
The pivot
And unlike previous approaches, we now had a perhaps not-so-secret weapon. Me! I'm kidding, but I do bring a bit more transparency and eagerness to share what we've been working on with customers and partners who would listen and provide feedback. Based on your feedback and a clear prompt from leadership to focus on the editor's main experience, we pushed out the date a bit further and started bringing on more teams who then turned that initial backend API to a production-ready system, added Content Manager caching to benefit all UIs, changed the time stamps to user time for proper cloud deployments, and finish the remaining editorial UI work in parallel across 2-3 teams.
To be perfectly honest, this is incredibly challenging yet rewarding work. My role, however, isn't to do the work but to prepare my team's work, represent our personas, and align with everyone else's work.
If you appreciate things like the new page and multimedia editing experience, recognize that was definitely us, but not "my" team. Like I hinted at before in a previous post, the surprisingly best part of the project wasn't when I got to create requirements for some interaction, it was in supporting and cheering on others to make those changes while also doing the research, taking in customer feedback, and incorporating feedback.
I can't take credit for the actual work in researching, designing, building, and testing this new experience, but I am proud and glad to have played my part as a good steward in bringing people together, representing our personas, and sharing the progress along the way.
Feedback welcome!
And when you see what we built and have an opinion, suggestion, or question, please bring the feedback. Let us know. I rebooted Tridion Sites Ideas and worked with our awesome Community team to reboot all of SDL Ideas for a reason. Aside from the fact that I was volunteered (voluntold), it was also to move the thousands of emails, messages, and tickets from wishlists and spreadsheets to a transparent list of requests and feedback from the vendor. There's no way we could ever get to all of them. But now we have a regular process and transparency on which of the community ideas align with the rest of the community and product management.
If I were to do it all over again, I might have even prioritized even more for an even sooner and smaller release. I could say "no" a bit more often than I do. But then we'd just have a new new Experience Manager rather than a new content explorer!
Ultimately, whoever cares the most or touches something first gets to decide. So if you really want to shape a community, product, or experience, feel free to MidasRule your way to offer ideas or even apply to the company.
This is one of my last posts in the current, soon-to-be-former role of product owner. I have a chance to work a bit longer with SDL now that I'm in the US so this wasn't a cross road so much as a literal flight across the Atlantic and homecoming of sorts. ;-)
It's yet another step towards the product becoming what it ultimately must become. And yet another step for me to bring together a touch of art, some content, some hopefully on-target humor, and lots of sharing into the next adventure.
Do thank my colleagues on a job well done and sure, offer them some good feedback. :-) I'm thankful and impressed to have had a chance to be yet another good steward to Tridion Sites in the dream job abroad at the "mothership!"
Edit: Mentioned our Amsterdam photographer, Florencia Jadia. Do reach out to her if you're looking for your own photo shoot in the Netherlands.
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.
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:
- SDL Tridion Lisp Mediator (Templating)
- Managing a blog with Tridion, directly connecting to the Content Manager Core Service
- X-box Kinect to manage content
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.
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.
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.
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.
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.
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.
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.
Research
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:
- Just engineers
- Engineers plus quality assurance, QA
- Engineers, QA, plus a part-to-full-time Scrum Maser
- 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.
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.
Experience
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.
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.
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."