It Starts with a Product Idea

You start with a fully-formed, marvelous idea for the product to solve your problem. This then gets reviewed to confirm its awesomeness and gets added to the product plan or backlog. From epics to stories to specifications to implementation, your idea gets transformed into one or more product features and is released to everyone, ready to solve the problem you had... two-to-three years ago.

Except that's not quite how it happens.

Lots of Familiar Ideas

In enterprise (possibly any) software development, the ideas are plentiful, evolving, and fleeting. Suggestions repeat and even compete with each other. Anamnesis reigns, where no idea is really new, just a recollections from past lives projects and other products.

For depressing inspiration on the relative importance of ideas, see Idea Guy Bill Gross's Ted Talk (hint: the idea is only part of the success equation).

As a product manager, I'm now part of a familiar process of prioritizing what we build without being too concerned with how it's built.

What I didn't tell you back as a functional consultant, the reason you liked (or didn't like) my functional designs was because of you, my dear technical consultant. I found a match between what the customer wanted and what you would likely implement.

• You liked automation and the Event System? Sure, it's part of the design toolkit.
• Content Delivery pro? Perfect, let's go dynamic with "widgets." Editor configures the Component, you deliver the results with a few Content Delivery API calls.
• Container components are your thing? Sure, we'll go modular but not dynamic just yet.

I helped discover the WHAT; you figured the best HOW.

Though technical formats should not dictate a proper content model, architectural and technical constraints actually help a design (see Design of Design, a nice follow-up Brooks' Mythical Man Month). In past business analysis roles I worked with developers and business owners to convert marketing and business owner wants into system needs.

Now I'm one of the "business owners." But my focus is still on helping the customer and their content editors.

Experiencing User Experience (UX)

I get to work with another awesome team that's even more focused and dedicated to the user's experience. As much as I loved working with implementation teams to build next generation websites, your personas were not my personas.

As a client, partner, or PS developer, you care about agile development processes, high-quality websites, and manage-able website code. Your primary persona is the website visitor rather than the editors. But the editors are my personas. And now you are also one of my personas.

Philipp Engel, SDL's UX Group Director, describes the team and the evolving process between Product Management, User Experience, and Product Development:

• UX Story Behind SDL CXC
• Building the UX Community at SDL
• And more recently, this introduction on SDL Community

Regardless of your experience with Tridion, please take a look at the slides, read the introduction, and consider joining the broader SDL UX community.

Beyond Feature Filtering

Having "field experience," I care about product features and have my own wish list of product changes. Paradoxically, the focus shouldn't be on features. If we look instead at what our users need to accomplish and what critical tasks they do over-and-over, we can focus on things we can improve qualitatively and quantitatively (read about data-driven design in our UX group).

A messier alternative is taking the few hundred (or thousand) ideas and then weight them by:

• Cost
• Appeal to stakeholders, the market, analysts
• Timing
• Size

But the point with feature ideas isn't to Catch Em All. You want a cohesive, comprehensible set, not a random selection filtered by attributes

Quick, pick the best ones by cost, appeal, or size. Source: Kotaku.

Discipline isn't just about saying "no." It's about saying "yes" to the right things. UX strategy helps us discover the right things based on the product vision and objectives along with well... the user experience. Organizations with "digital experiences" (websites) understand this and apply everything from A/B testing, to user research, to Top 10 Task Analysis to improve their customer's experience.

Since changing roles, editors are still one of my key personas and I'm still not responsible for the technical solution. I help highlight the problems; understanding the user's experience is critical to what we do. I'm looking forward to doing more than idea filtering.

In my next post I'll continue on user experience design, looking at some of the differences between website and enterprise software design and how the community can get involved.