Showing posts with label SDL Web. Show all posts
Showing posts with label SDL Web. Show all posts

A Year Or So in Product Management

After joining SDL and making an intrastate move from San Diego to San Jose five years ago, I posted what the first month was like.

Now I take a look back at the past year or so that started with an international move from San Diego to Nieuwegein, a city in Utrecht in "Holland" aka The Netherlands, near the end of 2015. After finding an unfinished rental, BSMSO did much of the work to fix up the place with paint, laminate flooring, and a yard complete with a small picket fence. The kids helped a bit too.

Can you dig it?

It's small, but it's still a picket fence.


Going Dutch 

We're loving our new home. Local stores are just around the corner along a wooded path and interesting places are a relatively quick drive or train ride away.

A walk to the local market which includes an Albert Heijn, of course.
To enjoy Dutch culture you can do things like visit Gouda. Yes, it's a place. And yes, it has cheese.

There are beaches here, just like back in California. Sort of.
I sometimes forget I'm in Europe, especially at home or when driving the A2, where big flat fields and livestock remind me I'm not in California.

Other details give a parallel universe vibe where traffic lights are on the near side of the street instead of across the street. "Aluminum" soda cans attract magnets. And snuggles isn't Snuggles, but rather Robijntje.

I'm not partial to fabric softener, but this bear stood out as one of many things that have been localized to this market. So much is familiar, yet different.

They have Renaissance fairs just like back home. But with castles.

Learning Dutch

Though I've entertained the idea of learning Dutch I haven't tried in earnest beyond the occasional lesson on Duolingo, Somehow I'm picking up the odd phrase or word through osmosis with phrases like:

  • "Ik ben" is "I am."
  • "Korting" means sale a discount. Like in the US there's always a sale, so it doesn't mean much except that you're looking at some type of advertisement.
  • "Alle-" means "all," as prefixed as an adjective in front of another word
  • "Lekker" is useful when ordering food or eating out.
  • "Met" is with, "of" is or, and "van" is from.
  • And "-je" is a way to make something diminutive, similar to the "-ito" in Spanish.
I've heard (from this guy) that learning an additional language might interfere with whatever other (secondary) language you already know. For Brits that might mean Dutch interfering with the French they may have learned in school. For a San Diegan that might be Spanish. I had an odd moment at a local Chilean Independence Festival, I was wondering how I could actually read a sign until I realized it was in Spanish rather than Dutch.

Cross-Cultural Observations

I've had Dutch colleagues and met a few of my current coworkers before moving here. The thing about Dutch (or any) stereotypes are that there may be some truth in them, but they definitely don't apply to everyone. Make assumptions at your own peril.

And as an international technology and services company focused on content and language, a good number of my colleagues have origin stories that started elsewhere. The thing to notice isn't the short-sighted fear that people grow and move on to other roles and companies. It's in how they come together from different backgrounds (work, culture, nationality, you name it) to further the mission. Where you're from doesn't matter as much as where we're headed.

Here are a few that have served similar roles at work, from the Floridian-New Yorker originally from Portugal to... I better not guess (actually I know most, but 1. don't want to leave anyone out and 2. give away personal info they haven't shared themselves). They all somehow found their way to the Amsterdam office at some point coming with various backgrounds, cultures, and nationalities. All have a passion for technical products and services.
One of the strangest personal adjustments is meeting Filipinos abroad. As a Filipino-American born and raised in Southern California, most Filipino-speaking people I've known are either family members or are in the US through the US Navy (through service or marriage). When I hear Tagalog or meet people speaking English with a Filipino accent, it's surreal sharing part of my cultural heritage but not the American part. What do you mean you're not a Filipino American? I'm hoping my children's status as "third culture kids" will be to their benefit in the long run.

At work and in my public interactions, though, I guess I represent America more than the Philippines. Speaking of work...

Work

New role. New shoes, of course.

After getting proper footwear, I focused on the new job which included much of the past role of knowing, explaining, and sharing about the software plus:
  • Customer meetings, events, and online/in-person presentations
  • Research, including meetings, emails, online searches, surveys, customer meetings, and more
  • Internal meetings including backlog grooming sessions, acceptance meetings, stand-ups (for now), and the big go- no-go meetings.
Occasionally we have to solve interesting problems.

The engineers either identified an interesting solution or an interesting problem. 

Not all problems are of the software variety.

Prioritizing prioritization.


Changes

Within the year, I've also had slight adjustments to the role:
  1. We dropped technical from the title. It's product manager, without a qualification.
  2. I started working with Translation Manager and External Content Libraries as "my" products.
  3. Most recently, I'm now working with Experience Optimization and Audience Manager as part of an integrated, well integrations team.
Someone joked I'm the new "previous-product-manager's-name," I asked if I should grow out my hair to match hers. ;-) Hopefully I'll live up to the expectations but my Facebook pics will never rival hers.

Actually, I did have long hair in a past life. This is a slide from my SDL Connect presentation. Some change is good.

I'm still helping a bit on usability and user experience, representing and bringing the customer's voice in grooming and design sessions. We made some changes for editors this year and there's of course more changes to make.

Releases

I've almost forgotten what it was like when you had to wait over a year for a Tridion release. Since moving to the Netherlands, I saw the team release Web 8, then helped a bit as they followed up with a Web 8 cumulative update (8.1.1). Then we had the Web 8 mid-year cloud release and my colleague Onno shared a Preview of Web 8.3 and Web 8.5 before we had the actual Web 8.5 release this month. Even better is the fact the SDL Web Cloud docs reflect the latest changes. In terms of cloud you should reference dates rather than versions.

Community

Along the way I rebooted SDL Tridion Ideas while my other colleague Bart released DXA several times (I'm losing count) and started moving extensions to the official SDL App Store with the help of Mark. See an example for a sneak peak before we release the rest of the extensions.

Change is coming.

As an even bigger initiative, we're working on reinforcing this cadence by adopting similar practices used by colleagues in Language (SAFe), which I should share about as we go along.

Sharing

From wide-eyed MVP winner, I've found I could encourage others to share and then encourage and recognize others that create sharers. For example, after joining the Amsterdam office, at least five colleagues started blogging (two in UX, two architects, and a fellow PM). ;-) I'm working on management next.

And speaking of community, I've posted much (much) less on CreateandBreak (Disruptive Innovator) while finding my new Product Manager voice on SDL Community. See:

Bring on 2017

Let me end 2016 by revisiting Nuno's Staying True to (Y)our Legacy post. The context may be different but the advice remains for organizations and individuals alike. I'm paraphrasing his list of facts into 6 points:
  1. Focus in order to grow.
  2. Recognize your legacy, user your strengths and let go of what isn't working.
  3. Help customers to be relevant to their customers.
  4. Be a good steward and let others shine. 
  5. Play nice with others. Don't try to be all things for everyone.
  6. Embrace what others love in you.
Through choice and aptitude, as shaped by our environments, we often have certain skills and abilities that make us a best fit to solve certain problems.

For me, that means bringing the right people and technology together to solve the right problems. Though "connect" was a theme for SDL this year, I've used the phrase SDL Connected before and believe connection is the perfect focus point for SDL Web's integrations. A good part of my past roles have been about connecting systems while bringing developers and the business closer together, which makes my current role a perfect fit.

That doesn't mean it'll necessarily be easy. Bring on Product Management Year Two.

Tridion Developer Summit 2016

Congratulations to Robert Curlette, the sponsors, and fellow presenters on another successful Tridion Developer Summit (TDS) 2016!

I want to share some quick observations as a presenter and fellow attendee as well as advice to those wanting to present or represent a vendor or partner. Oh and there'll be pictures at the end.

Context Matters, Especially for Developers

Tridionauts really love their IDEs. From DD4T to Alchemy GUI extensions to XView templating, implementers will find ways to do everything in their IDE of choice. Call our own Content Delivery API? Nope, they'll wrap it in DD4T. XML Configuration? Nope, they'll do that in a class in Alchemy (intellisense ftw!). Individual Template Building Blocks? Nope, instead maybe create a single Template Building Block (TBB) with the logic in its own MVC application in the Content Manager (TOM.NET) and call it XView.

By the way, our own DXA in Azure appeals this type of persona. As much as Tridionauts like Tridion, I see the work in these projects supporting the idea that Web developers want to develop. The product, extensions, and community work to make that easy.

Folder Practices with SDL Web/Tridion

I've been asked about folder best practices for SDL Web/Tridion a few times.

There is no single best practice for folders, though there are a few strategies that may fit you use cases based on what matters most to you. You manage folders mostly in the same way as any other system that organizes items, however, Tridion has three features that influence how you organize items:
  • BluePrinting
  • Different types of items (Components, Pages, Keywords, and External Content items)
  • Authorization
The Functional Design training describes three basic ways to organize folders:
  • By content type (schema)
  • By channel / site
  • By department or business unit
Most organizations use a mix of these approaches. You might also use dates to “archive” folders as well. These translate into familiar practices with corresponding trade-offs, starting with your top-level folders.

Congrats 2016 SDL Web Community Winners!

Congrats to the SDL Web 2016 Community MVP Winners!

Five quick tips for a successful year:

  1. Enjoy the uber geek status. Be sure to get to the retreat if you can. It's awesome.
  2. Keep sharing. Year two is harder than winning the first year.
  3. Don't under-appreciate what you have to offer.
  4. Don't get complacent or over-confident either. Winners aren't "the best," though the best often share.
  5. Connect with others and encourage the next generation of sharers.
To previous winners that "fell off" this year, welcome to the alumni group. Here are thoughts back from 2012 on having MVP alumnus status. Big thanks to those that shared less but maybe mentored more.

For anyone else interested in this award, 2017 will be even harder for a few reasons:
  1. Community members can get an SDL Web 8 developer license for research and sharing. The list is growing. Don't wait to get started.
  2. Alchemy.
  3. DXA.
  4. DD4T.
  5. The Next Big Thing in the Community (I've seen it. You're not ready for it. It's impressive.).
You may have read how to win my vote in a post from last year. That's old advice. To join the 2017 MVP class first join today's community. Then optionally see what everyone else is doing. And then share more than everyone else.

Tridion Doesn't Work That Way...

This post contrasts things you may or may not know about Tridion (SDL Web) connected by an embarrassing moment in my role as a product manager. Let's talk about too much knowledge, not enough, and why I'm not asking you to share this time.

Too Much Knowledge... Can be Embarrassing

We were recently discussing the idea of "tagging" content in SDL Web Experience Manager (XPM) as seen in the rough wireframe below. This specific idea won't end up in the final product without a bit more discussion, validation, and iterations. Or it might get swapped with something with a higher priority.

Rough wireframe exploring the idea of "in-context" tagging. Our UX designer stressed it's very rough. Don't tell him I showed this to you.

Differences Between Website and Enterprise Software Design

In my last post, I described (SDL Web) product ideas and the user experience. I continue by contrasting design for website visitors versus for those that manage such websites and end with a thank you and invitation.

Disclaimer: these are my personal views, biased by a business analyst and CMS background and lots of love for my product and its community.

Design Alignment

The biggest difference between working with our customer's designers and SDL's UX team is the organizational alignment. As part of a given customer's digital experience ecosystem (read about being a Good Corporate player by Nuno Linhares) the CMS implementation is often downstream of Web design where the user experience design, wireframes, and even HTML often come before the CMS implementation. The goal of "happy customers" is the same, but the definition of customer isn't. Your persona is not my persona.

When Alignment Works

The best digital agencies and front-end designers understand content modeling and content strategy as they create great experiences for website visitors that the CMS and developers can implement and support. They think semantically, adopt approaches like BEM, and follow thought leaders like Gerry Mcgovern or A List Apart. They look holistically at website visitor goals to help solve real business and user problems.

The Pain of Misalignment

I haven't seen horrible designs in my projects, just the occasional design that didn't quite meet editor expectations that didn't account for long text, more/less content, and other changes to managed multilingual websites. Completely disregarding the existing content/data models and technical constraints means a website design isn't just a design, it's a proposal with new requirements and functionality. Often I've seen what Gerry McGovern would call "tiny tasks" creep into the design, to the dismay of the website builders and eventually users.

New requirements and functionality aren't bad on their own. It depends on what business problems you're trying to solve beyond "a shiny new website." This brings us to our own designers and UX team. When looking at our editorial and developer scenarios, we have to balance desired functionality with existing data models and constraints.

Web design is great when aligned, otherwise in a misaligned corporate Web development environment, you might see familiar elements of this amusing IT meme:
View post on imgur.com

Solving Business Problems

Though there's some overlap with typical website visitors, our users are corporate employees, contractors, and consultants that have built "business critical" systems with our software. Our disciplines each have their focus to support an innovative user experience. Philipp explains better with this slide:

Source: Building the UX Community at SDL

User Experience Community 

Though Product Management has plenty of product experience (a few decades worth combined), to continue to evolve the product lines we work with UX and Engineering to innovate in the intersection between people, business value, and technology.

With hundreds of Tridion-related blog posts and even more Tridion questions and answers, I'm fairly comfortable working in the open. If you haven't had the chance, give us feedback, share your ideas, or mention your open source project in the posts and sites below. Be sure to participate on SDL Community.
Oh and thank you. From my first posts on the old forum to an unexpected community award (awesome!) to the many times I was corrected learnt something new, you've helped me solve problems and better communicate solutions. It's been an amazing experience so far that incidentally turned into practical training for my new role.

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:
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.

The Presentation that Launched a Tridion Blog or Two

I was an SDL Tridion customer for four years before I joined SDL as a consultant. Four years later I'm hoping I can make a difference for another four or more years in Product Management. Let's start with a reminder to share more.

In February 2012, I gave this presentation to a room of peers. More than few started blogging shortly after. ;-) For the next Tridion blog you find, see if it happened to start in or around March 2012.



It took me this long to get the time (courage) to finally share this presentation. I'm trying to follow my own advice to continue sharing in a new role. What should I focus on?

The Future?

With the help of Product Marketing and UX, we released posts about the future of SDL Web. It's hard sharing about the future mainly because I'm not building the future, but rather helping predict and prioritize the future.

The future sounds so great until... expectations. It'd be too easy to become the Peter Molyneux of enterprise software development.

The Past (~300 Posts)

I learned some things in the past role. But it's odd being close to 300 Tridion-related posts since 2011 (267 here, 13 on TridionDeveloper, and 13 on SDL Community/TridionWorld), while not being sure what to post next. Though I still have a few more topics left in my "tips for Tridion consultants" blogging queue, it's time to move on... to the present.

Present

After tasting what it's like blogging about the future and getting my fill of the past, let's continue collaborating in the present.

I've been recently asking for your feedback on Tridion Meta in terms of custom reports, commenting features, and your extension ideas from the Tridion Developer Summit. I should be clear that I'm looking for your pain and needs (while attempting to predict the future) rather than features. Features for the sake of features are overrated, but we can cover that in another post.

I think my next post might be on how the Idea Fairy (or Idea Fairy Tale) works, but who knows what the future will bring?

What to Implement in Tridion First?

In a case of role-reversal from Functional Consultant to Product Manager, I'll soon have opportunities to prioritize development tasks.

I've told customers they might (should) prioritize based on their market/product/content strategy. For example, a client asked how to prioritize their website redesign from a Tridion perspective. After giving my feedback, the client pointed out my advice differed from my project manager. Oops.
  • My Project Manager said to prioritize by difficulty.
  • Separately, I suggested prioritizing following content strategy.
I was saved by the fact we were both correct from a CMS perspective. Combine perspectives to get some sagely advice:
Implement the harder, complex, and critical parts early. Use content strategy and business value to choose between tasks of equal complexity.
Use a top-down/outside-in approach to manage buildable sets of work for your sprints focusing on the hard, critical parts first.
  1. Global “page template” elements (global navigation, footer, etc.)
  2. Main editorial content and your main page/content types
  3. Shared functionality that are not on all pages
Without page templates, you don't have pages. Without content, you don't have content.

Your content strategy is aware of quantity as seen in a content matrix, inventory, and/or sitemaps. From a CMS perspective there's value in “templating” something used 100s of times.

Remember that business value and metrics aren’t necessarily the same. Focus on the popular parts and perhaps postpone elements that don’t help your customers. Convince business stakeholders using numbers, customer feedback, and research.

In practical terms:
  • Gather the latest site map and content inventory information—reports or the previous spreadsheets.
  • Find or get in touch with whoever owns analytics (“hey, is this page popular?”).
  • Add this to an outline of the FDD or whatever document manages your deliverables (work breakdown structure, Gantt chart, or agile board).
In the end, the advice was simple if not necessarily easy: prioritize according to your strategy. The hard part now is that I'll have to take my own advice for a change. ;-)

Preparing for Your Internal Demo with SDL Tridion (SDL Web)

Don't wait for the requested internal demo to prepare for the demo.

With SDL Web (Tridion), there are a few things you can prepare from project start for any and all internal demos in the future.

This post has four points:
  1. Think with +1 more in mind
  2. Use the Digital Experience Accelerator (formerly known as the Standard Reference Implementation)
  3. Go for quick wins
  4. Build the demo into your development process
Note: I wrote most of this post while I was still consulting, so read it from an implementation perspective.

+1 More in Mind

With BluePrinting, you can re-use and apply CMS functionality you've already implemented in another site, template, site section, or page. When developing the following types of functionality, you'll likely get a request for yet another version of the same thing.
  • Classify content. If you dynamically display tagged content by classification (Taxonomy), you'll likely need to also display other types of content by tags as well and will want to make the content type (Schema) configurable.
  • Translate content. If you allow translation for a given site, new sites may need translation. Even if it's "not in scope," a proper BluePrint design can support the request for translation when it comes.
  • Control website functionality from the CMS. If you let content editors present a form or other "widget" (CMS-controlled website functionality), you'll likely need a similar form with different content on a different page. Make the content editable and translatable.
  • Create a site. If asked to create a microsite, you'll likely have more requests. Consider sharing web application functionality within the CMS.
Be careful to avoid gold plating in any development process, but within reason consider how content management will evolve and take advantage of the tools..

One More Item or Feature. Not More Types.

Assume +1 more as in "we'll likely apply this functionality again." But avoid cluttering your content model and CMS entry forms with functionality that isn't ready yet. For example, if you need to display an image, assume you'll display more images but don't add video or audio options to your content forms until they're actually ready to be used.

Do this:
  • Category for "features" with a single keyword for "mandatory." This lets you add additional options later, but keep the forms specific to today's available options.
  • Have a field for images used in the current content model.
  • Design a scalable BluePrint and folder structure, starting with the Publications and folders you need.
Not this:
  • Add potential fields, Keywords, folders, or other items before they're needed. Or at least only use them in non-Production environments.
  • Add a field for video "just in case."
  • Add Publications and folders, "just in case"

Accelerate Your Implementation

Years of practical experience and expertise went into the Standard Reference Implementation, most recently released as the Digital Experience Accelerator (DXA). Use it. Learn from it. Know what Tridion is capable of. After seeing familiar patterns in the DXA, read about or even contribute to SDL's other open source initiatives.

DXA modules continue to evolve, but so far include:
  • .NET and Java versions
  • Modules for:
    • ECL
    • Media Manager
    • SmartTarget
    • Search (with both Solr and AWS CloudSearch support)

Quick Wins

You're busy installing, implementing, and developing but save a few moments each sprint or day to go for quick wins. The following take little or no development work:
  • User interface integration such as:
  • Translation, if already set up (for either Translation Management or just new Publications)
  • Sharing CM-side functionality through BluePrinting
  • Experience manager visual hints
    • Page type example url
    • Template icons
    • Component Presentation borders
    • Even the border colors themselves
  • Moving items up or down a BluePrint (only in SDL Web 8 and later)

Development Process

I've made the mistake of asking, "is Experience Manager in scope?" The response varies from, "I'm not sure" to "we're just going to get this done for now."

Whether you're a partner, customer, or colleague in SDL professional services, I'm explicitly telling you, as someone that's worked with Tridion since 2008, was part of SDL Professional Services from 2011 through 2015, and now in Product Management, that "yes, Experience Manager is in scope for all new SDL Web projects."

You want Experience Manager for SmartTarget, for mobile setups, for easy page creation. Don't go for inline editing without first starting with in-context creation. The best parts are the easiest.

In other words, in-context beats inline.

At the minimum, you should include the page button (via the page bootstrap script tag) for Staging sites. Regardless of templating approach, you can and should generate XPM markup for Component Presentations.

Now back to your development process. For any SDL Web-related code or functionality you deliver, you should expect the following:
  1. Experience Manager is enabled for this page
  2. There's at least one page type
  3. There's at least one (possibly custom) content type for each Component Template
  4. If you have a demo in your DTAP setup, your code and functionality should work on the demo environments.
*DTAP has long stood for Dev, Test, Acceptance, and Production. With the announcement that SDL Web 8 brings free developer licenses and if you maintain a separate demo setup, you might have DDDTAP. 
Let me end with some observations and warnings.

A demonstration of what you've built should be a demonstration of what you've built.

Good:

  • You know you're presenting well in a demo when the audience starts daydreaming about cool new functionality or asking about new features. If aligned with your agile process, an informal review demo should elicit feedback (read about sprint demos here, here, and here).
  • You're also doing well when your project manager wants to show the demo to the client, who wants to show it to the boss, who wants to show it to other stakeholders. I call this the Demo Onion because... layers.

Be careful:

  • Be careful when you're being compared to the latest new website, the client's competitor, or worse--you're competitor. In the demo, defer to your leads or if you are the lead, address or diffuse any concerns appropriately. After the demo, work with your team and client on how to fix issues and build trust before the next demo.
  • But be careful to manage expectations. A demo is not a requirements workshop and don't accept new requirements without validation from the implementation team or project manager.

When a project or program is going well, demos are exciting, well... demonstrations of what you've built. You'll hear, "hey, let me know you something!" rather than, "so, when can we have a demo?"