Lessons as a product owner: adding touch-screen support to a new enterprise UI

My latest product release introduced touch-screen support as part of a new user interface for an enterprise product that's been on the market for nearly two decades. The idea of improving the interface of this particular Content Management System (CMS) to meet modern user expectations using today's UI technology approaches was desired, expected, and perhaps overdue. However, touch-screen support as a non-functional requirement had a more contentious start that needed a bit of attention from user experience (UX) design, development, and quality assurance. As a product owner, I had to own the requirement to set both internal and external expectations for what it meant exactly.

This is a photo by my colleague and UX practitioner Luke Chen, showcasing the mentioned UI working on my iPad. The ultimate design and implementation changed a bit, but touch-screen support was ultimately delivered with the release.

Clarifying, measuring, and prioritizing touch support, especially in the last few sprints before an on-premise release, was a challenging yet interesting exercise. I've learned a few things that might be useful for your (or my) future projects and product releases, especially for product owners working with cross-functional agile teams.

The lessons for this and similar requirements have been three-fold:

• Own it. A requirement isn't a requirement unless you (as a product owner) require it.
• Be agile. Keep it lean and nimble. Each feature or change has downstream, not-so-hidden costs.
• Steer just enough and in time. More alignment upfront. Fewer meetings later. But more reminders on what's acceptable.

Own it

The earliest User Experience vision, direction, and designs mentioned touch support for this new user interface. And though the existing or now "classic" UI did work for some touch scenarios, it wasn't specifically designed, built, or tested against touch devices.

Several sprints into the implementation, the new UI mostly worked with touch scenarios though stakeholders and my development team had opinions of what we should do with touch including:

• Mobile scenarios seemed interesting from a sales and marketing perspective (with several hypothetical scenarios suggested mainly around review and publishing).
• It's more effective to consider and build for responsive touchpoints upfront rather than later!
• Touch-support is distinct from support for specific devices or even browsers on specific devices.
• We were getting some interest from customer's managers for mobile device support.
• And there were some examples and interest from actual editors for the feature.

In this kind of "chicken and egg" situation where people aren't interested in a feature because it doesn't exist and it doesn't exist because people haven't been interested, it's a good time to take a step back and remember you're the farmer, or perhaps geneticist. You have a stake in both chickens and eggs. You can introduce a new feature as well as influence interest in it, though it takes a bit of research, communication, and expectation management.

Research and negotiate

With several diverging approaches to consider my lead UI developer and I did two things.

1. Research. I reached out to our marketing intelligence analyst to gather what analyst reports we had on device adoption in the enterprise, did a few online searches myself, and started talking to customers about their interest in our UIs supporting devices.
2. Negotiate. Our UI developer lead started negotiating an exchange with management. We would avoid Internet Explorer support for our React-based UI in exchange for devices to test iPad (9.7") browser and eventual touch support.

Decide and then inform stakeholders

Based on the available research showing some tentative interest in having editors use our CMS on mobile devices as well as mixed adoption of non-laptop/desktop devices in enterprise organizations, we made it clear within the team and stakeholders that:

1. Limited touch-screen support was in. We would explicitly design for touch in general while testing against, and eventually supporting, iPad 9.7" devices (iPad pro and standard models). Though the market research showed Android devices outnumbered Apple, we weren't going to test all Android form factors nor try to have devices ready to replicate customer issues on any touch device.
2. A fully responsive UI was out. I didn't see a strong use case for completely mobile scenarios, at least not yet. It also didn't make sense to spend too much time investigating, designing, and testing for the review or publishing scenarios suggested, especially since we didn't have an end-to-end experience. I made sure to confirm the suggestions were insightful and valid, but not the most important thing to tackle at the time.
3. After confirming we're not far off from a touch-enabled UI with some additional testing, we'd continue to design, build, and test for touch support with the idea that the basics like navigating, interacting with the UI, and editing in the CMS would work, though we wouldn't over-optimize the touch experience.

I could have pushed for even less support, or even abandoned the requirement altogether by committing to just desktop support. But considering the costs to get this feature was not that hard and editors could work with our system outside of the office (we made these decisions before the Covid-19 pandemic) it was still a valuable feature. Also, the fact that the design already looked like it should be touch-friendly with ample space, breathing room, and checkboxes in its various lists risked disappointment by visually suggesting a capability that wasn't supported!

On the other hand, I doubt I could have pushed for an even more mobile device or touch-screen friendly UI. I wasn't going to risk not having any UI to be able to try to design and address for desktop, tablet, and mobile screens. I'm sure if I tried, there would have been well-justified pressure from both management and my developers if I was making a good decision. Ultimately, being a product owner with the right and responsibility to accept stories (or not) means you have control over your requirements though you still have to manage expectations and constraints on what you can realistically deliver.

Be agile

Our enterprise software is still deployed to on-premise customer installations. Though we follow scrum as our agile method, we still have a stabilization phase of a few sprints before releases which may occur every few months to about a year or so.

I've learned that to be able to release in good quality unless you have money to burn and flexible release dates (both of which may be in short supply in enterprise software development), it's best to build the minimum end-to-end experience needed to making something work to start getting feedback. You'll find out sooner-than-later that the back and front ends as well as other components connect correctly (or not) as well as get valuable customer feedback.

Sure, keep future scenarios in mind. And perhaps taking an iterative, agile approach might cost more in the long run. But you cannot predict how everything will go nor how customers and end users will react to what you deliver. As an example, while working on a screen that showed the publishing status of items in our CMS, we confirmed edge cases with our architect and developers and came up with a fairly "sophisticated" screen that had refresh options to check the targets for each publication.

One look by our partners had them asking, "wasn't this supposed to be a simplified interface?"

Luckily, with just some time spent on design but nothing implemented and no quality assurance (QA) needed, we were able to create a much simpler screen, better for both us and end users. This scenario happened several times where we were able to adjust or tweak our designs or implementation as we went along, rather than all at the end.

Similarly, with touch support or any other non-functional requirement, every additional scenario and use case we added meant we had to design, build, and confirm it works across our supported browsers using touch, mouse, and/or keyboard. Each story has downstream not-so-hidden costs. Every difference to layout, interactivity, or behavior meant yet another thing to confirm and validate and test, both from a quality assurance as well as a usability perspective.   

Steer enough and in time

I had a great experience steering a friend's boat in the canals around our past home in Nieuwegein in the Netherlands. My friend, the skipper (captain) explained that while keeping an eye on the horizon, you can tell if you're on course and how much you're drifting one way or another. You want to be on the correct side of the buoys, avoid the shoreline, and maintain space for course corrections such as avoiding a barge or other vessel.

If that tree way off in the distance is rapidly moving to the left compared to a spot on your vessel, you're turning too hard to the right.

For the new UI, we didn't quite run aground on the rocks of touch screen support, but we did get to a spot where we started gathering more iPad Safari-specific bugs than I'd care to admit. And this list of issues started competing with the rest of the work we wanted to finish.

To help course correct and for the sake of transparency and "alignment," I raised our status with product management and our quality assurance manager, who managed the QA engineers on my and everyone else's team. Ultimately, we got what we needed as we confirmed we would keep the touch requirement, document any remaining known issues, and prioritize these touch-related bugs against everything else that needed to be built or fixed.

In hindsight, I probably didn't need as many meetings. I already represented our user personas to my development team and was connected with management. I was already in a position to decide and communicate what's in or out and to prioritize touch-related bugs against everything else.

So in the future, I'd take the time to have more alignment meetings upfront, fewer meetings in general, more actions, and a smoother blend of stubbornness and flexibility. I would revisit basic expectations in the form of the team's definition of done and acceptance criteria, especially as teams or team members change.

I've learned to keep stating your expectations and asking for the team to build and test requirements until people make fun of you for it.

In the end, like a good skipper, I've learned to better steer where we're going by owning requirements while following an agile approach for minimal, iterative improvements. Keeping an eye on the horizon lets you make smaller adjustments along the way. If everything and everyone was predictable, you wouldn't need agile, nor perhaps a skipper.

That's about it on the lessons I've learned on owning a (touch-screen support) requirement, being agile, and "continuous steering." It's probably worth noting that we also tried to avoid the sunk cost fallacy, though that could be explored in a future post on some of my past "mistakes" which were probably (hopefully) successes in disguises.

---

Here are some "meta" notes on this post and its capitalization for title and headings:

1. As a post on alvinreyes.net as opposed to createandbreak.net, this post is sharing a bit on my own journey, lessons, and advice with product management and specifically my recent work as a product owner. Though astute readers or those with access to Google can easily infer which product I'm specifically talking about, this is less about that product and more about product thinking or thinking about products.
2. The same unmentioned product started following sentence-based naming conventions for things like labels in the UI. Though I'm used to Appropriate Title Casing, apparently this is a thing in the blogosphere (see this post by Brian Jackson from Woorkup) that I'd also like to try.

My Most Recent Journey

I'm a fan of Star Wars, Star Trek, Harry Potter, and a slew of other science fiction, fantasy, and popular culture. I once wondered if enjoying such entertainment is a guilty pleasure. Is it fair that I get to enjoy such science fiction and fantasy when others struggle? But I've realized the world would probably a better place if more people could be in a position to connect and form communities around their favorite creators and their fictional worlds. This assumes people's basic needs are met first, so we're not quite there yet.

Coincidentally, I was born and raised in San Diego, home of Comic Con, which celebrates rich entertainment mediums from comic books themselves to the latest incarnations in digital media.

Central to many of these stories is the Hero's Journey, which reflects the call-to-action and changes some protagonist faces before returning back as a changed person.

I don't quite consider myself a "hero," but I can say that I've returned from my own journey in understanding and helping a technical community and its product. The short version is a decade ago my company was looking for a system to manage content. We purchased Tridion, an enterprise content management system. I learned about it, shared about it, and won an award in 2011.

After consulting for a bit, I moved to the Netherlands to help manage the same product arriving in September 2015 in Amsterdam with family, 2 dogs, and 8 checked luggage.

Five years and several product releases later, I return to San Diego, older, wiser, and heavier with family, one dog (we had to say "goodbye" to one of our chihuahuas while abroad), 2 cats, and more luggage than I wish to remember. I believe I was a good steward for my beloved product and have left my team and organization in a somewhat better state than when I joined.

Most of all, I think I changed in my thinking, habits, and communication skills. I've finally put a fascination with leadership into regular practice as a product owner. I've brought creative hobbies like performance and digital media editing to conference speaking, customer demos, and webinars. I've mentored and have been mentored. Ultimately, I was able to get smart people on the same page to solve tricky problems with solutions validated by actual customers.

I've blogged about crossroads before, but I'm not quite sure that's the right description for this kind of homecoming. Tagalog, the a Filipino language has the word "balikbayan" to represent homecoming, but that doesn't quite feel right either as I associate the word with happier returns and things like balikbayan boxes. Oh and technically, I think the term refers to returning home, to the Philippines.

Oddly, being a "native English Speaker," albeit with a Californian accent, makes me appear abroad as an American first, and then Filipino-American next, if even that.

I'm writing this during the COVID-19 pandemic at a short-term rental, waiting to make sure we're not sick before joining family for a longer-term stay. We're paradoxically busy setting up life in the US again while slowly fighting cabin fever and boredom with family, dog, 2 cats, and more luggage than I wish to acknowledge. We have online accounts to review and update. We have "offline" accounts to close or otherwise transfer from the Netherlands.

Limiting exposure, wearing masks, and seeing closed stores makes being "home" like some post-apocalyptic scene. This next journey will be something else entirely, something that's a mix of really being home, near-yet-distanced from family, and digital transformations. Perhaps we'll find a permanent home sooner-than-later, but we'll have to see if that's in the realm of science fiction, fantasy, or reality.

Different Platforms for Different Audiences

I haven't maintained this website for a bit, mainly because I represent my work and personal personas elsewhere, mainly in my company's community platform and my "personal" career-related blog for work and Facebook for personal stuff.

I've been less active on Twitter, likely because it's yet another platform to try to keep up with and I haven't needed to be visible to the broader community. But also I've seen how the Twitter platform and community itself lacks a bit of context, where a few years ago people were losing jobs for things said or taken out of context. I'm sure some of the situations were either justified or the opposite, blown out of proportion. Though I doubt I could have made the same "mistakes", but who knows. It's nice to see how Twitter has contributed to more egalitarian changes such as #MeToo and #BlackLivesMatter, but now rather than a wariness of saying something wrong online, I wonder what I can contribute. Maybe I'll try again and save all my witty observations no one wants to hear just for my Twitter feed.

I probably don't have much or anything to worry about really, since my online reach is non-existent outside my technical community and friends. And even then, I've already earned a reputation for being pro-diversity and perhaps "no fun," when it comes to the lack of tolerance I have for inappropriate remarks at work. I've had colleagues say things like, "let's check with Alvin if that's sexist." So yeah, I'm the guy that will ask you to be careful what you say because words matter. 

Anyways, back to the topic of this post. I use different platforms for different audiences and topics. It doesn't go well when I mix them too much. For example one time I'm sure I pissed off family when I posted something on Facebook really meant for my work community. Conversely a personal rant about work on Facebook got back to coworkers but hopefully not to my rantee. Oops. Most recently, I shifted careers and location again, for a move back from abroad in Europe, in the Netherlands specifically, back to the United States. This was long planned from even before our move back in 2015, though it was the best of worse possible timing in the middle of this 2020 pandemic. After mentioning the move too many times across multiple channels, I got I think one personal recommendation on Linked-In.

Luckily, I think most of these moments have been forgotten or will soon be.

So... what do I write about on the website (blog) attached to my actual name? Apparently it's the "meta" contemplation of different platforms for different audiences, which breaks down into:

• Work-approved posts and "industry expertise" goes on the work community platform
• More personal observations that I wouldn't want work to own if or when I leave go on my personal work blog.
• Work-related updates meant for just colleagues goes on the internal work sharing (Yammer)
• On-topic, ephemeral work related updates or questions go on the work chat (Teams or Skype for Business)
• Off-topic communication goes on the unofficial work chat (Slack)
• Personal stuff goes on Facebook
• More personal stuff goes on Messenger to family
• And so on...

 Even on a given platform like Facebook or Messenger, I'll use different groups for different circles of friends, family, or colleagues. Oddly Google's foray into social media had such a "circles" feature, probably recognizing the challenge it is with managing so many contexts and people.

However, I think it's really hard to manage so many different groups, especially if each user has their own set of users in a given group and the communication goes both ways. There's something clearer when an online group's membership is transparent and voluntary for all participants.

However, it's probably useful to be able to broadcast (less interactive) messages to groups like "family," "close friends," and "not-as-close people in your network."

Okay, that's enough for this rambling post. I considered writing about this move back from the Netherlands but I'll save that for another post, either here or perhaps one or many of the platforms mentioned above.

The New AlvinReyes.net

I originally created my alvinreyes.net website to serve as my online resume circa 2011. I was completing my bachelor's degree and also wondering if I could become a consultant. But createandbreak.net, my Linked-In profile, and a career change (into consulting) made a domain with my name in it much less important. Oh and the fact that there are several people with my name online didn't help either.

I plan on keeping the domain but am moving it here to Blogger for now.

The old site served me well.

If you're new to blogging and just need a blog, Wordpress or Blogger would serve you well. Unique domains will cost you $10-$20 a year.

If you really want a small website to represent your small-to-medium business with some light integration options and design flexibility, consider a hosted solution (e.g. BlueHost or similar), which can run $10-$20 a month. Hire a web designer or small agency to get you started.

If you're an enterprise customer, well good luck. There are plenty of options, but my favorite is SDL Web aka SDL Tridion. ;-)

I Writer. I Professor?

(05-Nov-2011) Update: I went back to confirm my findings and based on an advanced degree,professor came up as a top candidate. Considering one of my first jobs was a peer math tutor, I currently enjoy a role as a software consultant which includes teaching others, and I love writing I’m sure I’ll end up in a related field.
I finally bought the series of assessments on MyPlan.com for $20. It suggested my personality and skills match engineer and programming-type careers. However my values and interests better fit high-profile or creative roles like director, musician, composer, designer, or creative writer.
Here’s my current breakdown and corresponding recommended careers:

• Personality (Jung-based assessment): ENTP or Extroverted, Intuitive, Thinker, Perceiver (matches architect, engineer, programmer)
• Values: achievement, independence, recognition (matches director, musician, design)
• Interests: artistic and social (matches interpreter, creative writer, composer)
• Skills: Engineers/Architecture and Computer/Mathematical (matches architect, engineer, programmer)

The “composite” score suggested “Technical Writer” at 75%. Awesome! This matches the fact I believe writing really helped and framed my career in IT.
However, that suggestion was was followed by “Marine Architect” and most of the above careers, each matching at around 68%. These are just assessments but it does reflect my varied interests and hard-to-pin down career path.

Years after my family encouraged me to not pursue a career in theater or acting after high school, I still feel the pull between a desire to be creative versus mathematically inclined. Perhaps I’ll end up writing about whatever I feel like.