Our Process

Prologue

Our product management process within the Digital group aligns with the Digital Product Development Life Cycle (PDLC), although it’s important to note for most of the work we do, only part of it applies to our day-to-day. The majority of what the Digital team ships are not “new products” as referred to in the PDLC. Our projects much more often fall into the “feature release” category. The following sections detail the way our group makes the PDLC our own.

As noted in our PDLC, the digital group operates in a “SAFe-ish” methodology. Some key elements of SAFe we have implemented across the organization are as follows: Program Increment (PI) planning - We plan work in 3 month chunks of time, each being its own PI. During a given PI, we are executing on work and planning for the next PI. Additionally, each PI kicks off with an onsite “PI planning” meeting to hear updates from leaders, reflect on the previous PI, and finalize planning for the one being kicked off.

• Planning for a PI begins with product and other teams marking “PI candidates”. These projects are then researched and planned cross functionally leading into a PI. As projects–or portions of projects–are “committed” to, they evolve from candidates to commitments. Commitments help our entire organization to communicate expectations to customers and other stakeholders, internal and external.
• Each engineering team has a minimum set of Jira requirements that must be met for a given project, but is given lots of flexibility in how they operate outside of those requirements. Projects are tracked in the Roadmap (RDMP) Jira project, and can be projects owned by Product, Engineering, Design, and beyond—however, they will all be prioritized against each other. Each design and engineering team creates Epics under RDMP projects, and can then use Stories and Tasks to break down work further. There are universal statuses for the higher level ticket types, which can be found here (LINK COMING LATER).

Project stages: Generation and Synthesis

We’ve outlined two stages of development: Generation and Synthesis. This format helps to create clear boundaries around the type of work–and the type of thinking–required for each stage. Generation is just as it sounds: Coming up with ideas, thinking about possibilities, identifying a north star and aiming for it. Synthesis is taking those ideas and possibilities, further defining them into something feasible and actionable, and finally executing. The sections below detail each stage into process steps and actions.

Generation

[image of generation section of figjam, plus a link]

Overview

Generation begins with an idea. The stage is then used to research that idea by talking to customers, reviewing relevant data, considering market needs, and thinking about the impact on Jack Henry teams and revenue opportunity.

Problem definition

When an idea is born, it should be tracked as an Idea in Jira Product Discovery (JPD). JPD serves as a lightweight tracker to link relevant research, other projects, and more. It also represents a space for Product to research ideas, prioritize them, write product briefs, and ultimately transition an idea into a project.

Ideas come from everywhere! Market research, latest technology, customers, simply watching users interact with our products, leaders, operations team members, etc. Ideas are born out of problems, and it’s a product manager’s role to understand and define those problems so our design and engineering teams can solve them. Inside of our product briefs, we define problems and utilize the Jobs To Be Done (JTBD) framework to build up a solid understanding of the various facets of a given problem—what are people actually trying to accomplish?

Research really begins when we decide a particular idea is worth exploring. PMs should work to gather both qualitative and quantitative data to vet the idea, which can be attained in multiple ways:

Qualitative Talk to internal and external stakeholders to determine ‘why’ this Insight might have value. Research other products in the space to see how they are approaching this concept. Is this actually a problem which needs solving?

Quantitative Utilize our analytics tools or partner with engineers to learn about usage or query for the data you need. You may even be able to find related research studies and articles. How large–or small–of an impact will this have?

As an idea progresses to the point where you’re ready to schedule a project, finalize your product brief and share it with the product team for feedback if you haven’t already. The project can then be considered by the PM team and leaders for addition to the Roadmap (RDMP) Jira project as an Initiative, where it can become a PI candidate. This is also where Generation becomes cross functional. The various statuses of an initiative are highlighted in the sections below, along with action items for each.

Action items

• Create an Idea in JPD, be detailed in your description, and add other weighting options like your gut feel for both Impact and Effort.
• Prioritize Ideas against each other within your domains. Each product manager should be able to articulate why their top 5-10 ideas are prioritized as such. Maintaining a well prioritized list of ideas forces you to better understand our customers and your domain.
• Create a project folder and write up a brief (INCLUDE EXAMPLE BRIEF), taking the extra time to fill out all sections of the template. The template is designed to ensure you’ve thought through the most critical components of a problem. All briefs must be shared with the rest of the product team for review when drafted—this helps the entire team stay informed and improves the quality of our briefs overall.
  • Create a project folder in the Projects folder in Drive, then use the ‘From a template’ option in Google Docs and choose Product Brief
• Review your Idea with the product team and, if approved, move to the RDMP project as an Initiative to begin the roadmapping and PI planning process.

Backlog

Where an initiative lives until a cross-functional team picks it up to work. When this happens, the status transitions to Ideation.

Once ideas transition to Initiatives in the Backlog, a series of Product Epics will be created. These Epics match those our design team uses and help us track the work we need to do during each step. They also provide a way for other teams to link dependencies on our work:

• Research - Continued research on a given project. When the brief is ready for prime time, this Epic can be marked complete.
• Ideation - Cross-functional possibility exploration. This is always done with design, and usually with Technical Business Analysts as well. During this period, operations should be consulted as well.
• Execution - Includes the tasks we need to complete as a project is developed by engineering. This includes acceptance testing, customer communication, and release.

Action items

• Ensure the Initiative has Components for all needed teams (data services teams, design, Mobile or Online, etc)
  • Also add Analyst Leaders to the “Team” field (dropdown)—this is an indicator to the QA/BA team to assign someone to help with user creation and acceptance testing
  • Learn more about components (ADD ANCHOR) below
• Schedule a meeting with design, the engineering managers of all needed teams, and your assigned QA/BA analyst (this person will have created an Epic and assigned themselves to it under the Initiative). This is an early ‘heads up’ and opportunity for input way ahead of actual work. This will also inform who should be a part of Ideation.
• Work with your manager to prioritize the Initiative among other Initiatives. This will help other teams to prioritize and estimate a start date.
• Once you begin working with design and/or Technical Business Analysts, and your brief is ready for further review, mark your Research Epic complete, and update the Initiative status to Ideation.

Ideation

A space for dreaming and exploring possibilities. Product, design, and analysts will work together to come up with solutions, always with design thinking at the forefront. The goal of this step is to ensure we arrive at a single user-centered and feasible solution.

Action items

• Create a Slack channel (see Slack channel format and etiquette here ADD LINK), invite the right folks, and add links to the Initiative and brief to the channel bookmarks.
• Reach out and schedule regular meetings with the assigned designer, the appropriate Technical Business Analysts, and your assigned QA/BA analyst.
• Initiatives should now be discussed with operations during Operations Impact meetings, to ensure our support and implementation teams know what’s coming and can provide input early enough in the process to allow for needed scope change.
• As a solution is identified, the product brief, designs, and any needed technical details should be prepared for Synthesis, and the Ideation Epic should be marked complete.
• At this point, the Initiative should be ready for consideration as a PI candidate. The PI field should be marked with the upcoming PI number, the Initiative status changed to Planning, and the PI planning process begins.

Synthesis

[image of synthesis section of figjam, plus a link]

Overview

Synthesis is straightforward as a concept, it’s taking the ideas mentioned above and synthesizing a solution that solves the problem. Every project that moves into the Synthesis stage should be in a place where a cross functional project team can review, discuss, estimate, and ultimately commit to building the solution in a PI.

Planning

This is where a cross functional team should review the initiative, the product brief, designs, and any technical details produced. The goal of this phase should be to arrive at a shared understanding of the scope so all teams can create needed tickets, estimate, and commit to work during a PI.

Action items

• At this point, the Initiative should be ready for consideration as a PI candidate. The PI field should be marked with the upcoming PI number, and the PI planning process begins.
• Meet with all stakeholders to discuss the brief, designs, etc and work toward estimates for each Feature. Features are estimated by other teams and marked on their Epics, and then teams should be prepared to commit to the work during PI planning.

PI planning

A high level overview is spelled out in the Prologue (LINK TO ANCHOR ABOVE), but this is where and how we prioritize and schedule projects. All the research and prioritization up to this point should be used to explore, estimate, and ultimately commit to the work.

Once items are committed to a PI, you have some clarity around when work will begin in earnest.

Develop

This is where engineers become fully engaged. Designs should be well underway if not done, and the backend engineering team(s) may have a Technical Requirements Document (TRD) in progress or complete. Technical Business Analysts and/or the backend engineering team(s) will typically conduct their own acceptance testing for the APIs once their work is completed, in advance of the end-to-end testing that will include QA/BA team members and UI engineers.

Action items

• The project manager or product manager should schedule recurring meetings to continue discussing the project.
• All necessary stakeholders should be invited to the Slack channel.
• Operations should be consulted again during the Operations Impact meeting. You should be able to go into more detail this time, share designs, etc. If this feature needs to be beta tested, this would be a good time to work with operations on good beta candidates and then work with those beta customers so you and they are ready when the feature is.
• QA/BA analysts will be available to help create users, so ensure they’re up to speed to help in this critical area.
• As all open questions get answered and engineers are actively coding, the QA/BA analyst should create a User Acceptance Testing (UAT) document for the end-to-end validation. They’ll share it with you and with the project team when ready.
• You should work with the documentation team on ops doc and knowledge base article creation.
• It’s time to start thinking about release and rollout. You should write a ‘Coming soon’ article for the Banno Statement over a month before release, with a ‘New feature’ article coming out the month ahead of release. It’s imperative that these articles answer common customer questions, such as “when can I have this?”, “do I need to open a support case to get it?” etc.
• Complete the necessary checklist items in the Execution Epic before updating the Initiative status to Acceptance.

Acceptance

The work is in a state where it’s ready for acceptance testing. The QA/BA analyst will schedule a UAT meeting where they run through the UAT doc while UI engineers share their screen and go through the various test cases in the document.

Any open items or issues captured during the UAT meeting or otherwise should be tracked on the team epic in some way. When all items have been resolved or noted for future releases, and code has been deployed, the status changes to “Release prep”

Action items

• Work with the QA/BA analyst as they create the UAT doc and schedule the UAT meeting.
• Help QA/BA analysts as needed while they follow up on UAT items and prep for deployment.
• Work on finalizing documentation while engineers are cleaning up UAT items.
• Once a project passes UAT and is deployed, move into the “Release prep” status.
• Button up Statement articles, beta preparation, and documentation.
• Ensure the necessary Execution Epic checklist items are complete.

Release prep

This status allows product, operations, and our go-to-market team to finish documentation, make sure customer communications go out as needed, and finally prep for beta testing.

Action items

• Finalize knowledge base and ops documentation in partnership with the documentation team.
• Host the operations handoff (LINK TO OPS READINESS PROCESS). For smaller projects this can be done during our monthly meeting, but for larger or more complex projects, a one-off handoff should be scheduled to ensure you have enough time with operations.
• Write up a ‘new feature’ statement article if this is going out soon. You could also consider mentioning it will be in beta for a time.
• After the ops handoff, reach out to enable your beta customers, and you should be set to transition into the Beta status.

Beta

• Most features should go through some amount of beta testing. Beta testing not only enables us to get feedback on what we’re building in a controlled environment, it also allows our operations teams to test and become familiar with configuration and support.

Action items

• You should already have beta customers lined up—the number of beta customers depends on how configurable the feature is, how risky a larger rollout will be, and a number of project-specific considerations. The operations readiness meetings will help you get these details.
• Reach out to beta customers to get the feature enabled, and work with operations to get that done (remember, part of this is beta testing the operationalization, so it’s important they help with this).
• Create and provide the customer with a simple beta testing plan. This can be as simple as a few bullet points or as complex as a version of the UAT doc—this again depends on the needs and complexity of the project.
• Communicate an ideal timeframe to testers—we don’t want beta to continue for months. Ideally you can wrap testing within a few weeks and proceed with rollout.
• Once you’ve successfully beta tested and either fixed bugs or noted feedback for future enhancements, you should work with the project team and with operations on the rollouts. Sometimes this is enabling an Ability en masse, other times it’s letting customers know they can open a support case—this varies a lot.
• Roll it out, mark the Execution Epic and the initiative Done, and party—you shipped something and provided value to our customers and their account holders! Don’t hesitate to post in #team-digital shouting out the wonderful folks who helped build it.

Key project considerations (ADD LINKS TO ALL ANCHORS BELOW)

On nearly every project, the following items should always be considered:

• What abilities or permissions are required for this functionality? Who’s enabling it, and how does access need to be granted? Are there new entitlements required for organizations?
• Do history events need to be created? If an action is being taken by anyone, the answer is almost always yes.
• What error messages do we need to ensure get accounted for at both the service side and client side?
• Are we introducing new hard-coded strings into our apps? If so, they need to be translated.
• What new screens or actions should be tracked with Mixpanel events?
• Does this functionality require new reporting, or that metrics are added to existing reports? Do we need to ensure a new data type is sent to the JH Data Broker?
• Should we consider creating new EES events for an action being taken? Do we need to consider how this impacts existing, or new, alerts?
• Is this an add-on which will require pricing evaluation and contract addendums for our customers?
• Is there a vendor we’re integrating with who needs to go through procurement?

Tools & other processes

Weekly updates

One of your first tasks of each week will be to let the product team know what your plans are for the week, and how last week went. Once you’ve oriented yourself, fill out this template and toss it in #team-product on the first day of your work week:

#1 Your top priority item for the week. If you only manage to get one thing done, what should it be?

Areas of focus Bulleted list of your other focuses this week.

Last week Bulleted list with a quick overview of what you accomplished last week. Hot tip: This is easiest to fill out as the last thing you do the week before.

Schedule Share your availability this week. It’s also helpful to include a note about upcoming PTO or travel.

Customer & sales support

While product managers don’t directly interface with customers through support tickets, we are often called upon as subject matter experts (SMEs) when questions come from support or engineering about expected behavior or desired changes.

OPS tickets (Jira tickets)

Customer support issues are channeled through jSource and then Jira for more efficient triage by Digital teams. The list of OPS tickets requiring product input can be found here. You will also be notified directly based on domain ownership, so watch your inbox.

Tracking down answers to questions can be time consuming, but it’s also one of the best ways to develop domain expertise. If you don’t know the answer, the #org channel in Slack for the involved backend engineering team(s) is often a good place to start for input from SME’s, or your leader can help point you in the right direction.

Stack Overflow

For details on Stack Overflow, see the full Product Questions process doc.

Questions in Slack

[Details about this process.]

Documentation

Project documentation

Google Drive project folder

• Brief (or Confluence)
• Ops doc working file
• UAT doc
• Related research notes, studies, PDFs, etc

Slack

• Toss links in the Bookmarks section of the Slack channel
• Initiative
• Brief
• UAT doc
• Designs
• Etc

Figma

• Designers will use Figma
• Don’t hesitate to use FigJam for whiteboarding—it’s very lightweight, collaborative, and often communicates a concept better than words.

Operations documentation

This is where our operations teams go to understand what a feature is as well as how to configure and enable it for our customers. Ops docs should be created during a project using the template in Google Drive, discussed during operations readiness, and added here before handoff. To get documents from Drive into the knowledge base, ping Joe Donohue in the #org-documentation Slack channel.

Customer-facing documentation

Our customers (and internal teams) visit our knowledge base to learn about functionality. This should be higher level than the ops docs, but provide enough detail so readers know what the feature is, and how it benefits them. Knowledge base articles should be created during each project, in collaboration with our documentation team.

Atlassian (Jira tools)

Confluence

We’re testing out Confluence for product briefs among other things, you’ll see documents here and there while we do this.

Jira Product Discovery (JPD)

Every idea or project should start in JPD as an Idea. There, they can be prioritized, you can write briefs and add supplemental information, and ultimately transition to our Jira project to get scheduled and built.

Jira

Jira is where we track all Digital work items. We’ll start with an Initiative in the Roadmap (RDMP) project (where other teams can also put Initiatives). There, we can prioritize Initiatives against each other, estimate the work required, and ultimately end up with a roadmap plan we can use internally as well as for customer communication.

Issue types

We have some amount of consistency implemented, which helps with coordination among all teams. From the product perspective, there are a few issue types we’re especially focused on:

• Goals - Organizational strategic priorities, which span several months or even years. Typically will be broken up into the issue types below. Goals are “solved by” Themes.
• Themes - Big problem spaces in which there’s work to be done. These are created in alignment with organizational strategic priorities, and help drive our communication and prioritization. Most Initiatives will “help solve” a Theme.
• Initiatives - A block of work amounting to the solution to a problem. Initiatives should be reasonably sized—small enough to ship, large enough to actually deliver value and solve a problem. Product briefs are written at the Initiative level.
• Features - Goals which are tied directly to job stories. Each feature should provide value and be something that can be built and deployed to production. This helps us to further break down work into smaller pieces that can be completed in a single PI.
• Epics - Each team creates epics under a Feature or Initiative, depending on scope. These are how every team tracks and commits to their own work. Product managers also create and assign themselves to an Epic for tracking certain tasks so other teams can link dependencies.

Components

Component is a field on Initiative tickets, and they should be filled out on every Initiative. They denote which teams need to be involved, and help other teams to filter and track all of their work. Here are some examples:

• Design
• Data services team(s) - Aviato, Discovery, Kayak, etc
• Client team(s) - Mobile, Online, Admin-UI, etc
• Admin-History-events should be used whenever a new History event is required. The design team has a great doc on History Events
• Admin-Email-templates should be used whenever a new email template is required (if you learn one is needed after a project has shipped, follow the instructions above)

PI fields

The key tracking issue types (Initiative, Feature, and Epic) have both PI and PI committed fields. Here’s how they work, using PI 9 as an example:

Initiative:

• PI = 9:
  • Before PI 9: Tentative PI candidate
  • During PI 9: Work is happening during PI (any team has 9 on their epic)
• PI committed = 9: The Initiative is expected to complete in PI 9 (All Features and Epics are done or committed)

Feature:

• PI = 9:
  • Before PI 9: (not tracked ahead of a PI)
  • During PI 9: Work is happening during PI (any team has 9 on their epic)
• PI committed = 9: The Feature is expected to complete in PI 9 (All Epics are done or committed)

Design or Engineering Epic:

• PI = 9:
  • Before PI 9: Tentative PI candidate
  • During PI 9: Team committed to working on epic during PI 9
• PI committed = 9: Team committed to completing during PI

Product brief

As soon as you have a brief for an Initiative, add the link to this field so others can easily find the brief.

Understanding abilities and entitlements

Nearly every feature we deliver touches abilities in some way. Whether it be because a feature is specific to banks or credit unions, specific to one core, or simply needs to be beta tested by a select number of FIs and users before general release, abilities are used by JH Digital employees (and FI employees in some cases) to limit feature availability to only those who should have it. This is a breakdown of our current abilities functionality:

Definitions

• Ability: Banno layer flags that both services and clients use to enable/disable and show/hide functionality.
• Institution ability: JH Digital employee facing abilities used to toggle feature access for an entire institution.
• Organization ability (restrictive abilities only, see below): JH Digital employee and FI employee facing abilities used to toggle feature access for an organization.
• User ability: JH Digital employee and (sometimes) FI employee facing abilities used to toggle feature access for an account holder.
• Restrictive ability: Abilities that are only enabled hierarchically (must be enabled at the level above in order to be enabled for any levels below, e.g. institution ability is required for organization ability to be enabled).
• Permissive ability: Abilities that can be enabled at the user level without the institution ability being enabled, and vice versa. The user level can override the institution setting in either direction.
• Calculated ability: The actual ability that impacts access to the end user. E.g. a user ability might appear enabled, and even be stored that way, but if the restrictive organization entitlement above it is disabled, the calculated ability will be disabled and the user will not have access.

Restrictive abilities

This is the model used by all of our ‘business’ abilities, such as ACH, Wires, User management.

Institution level Found in People > Config > Entitlements (unfortunate label, I know, we still call them abilities)

Organization level Found in People > Organization > Permissions (FI facing)

User level Found in People > Organization user profile > Permissions (FI facing) as well as Online > Settings > User management > Permissions > Top level permission (org admin facing)

Example scenario where FI wants to test a new feature during beta or otherwise:

• Banno employee enables institution ability
• FI employee enables an organization
• FI employee OR organization admin enables user ability for test users

Permissive abilities

These are our old school abilities. They’re used by lots and lots of features.

Institution level Found in People > Config > Abilities

(there is no organization level for these today)

User level Found in People > User profile > Config (Banno facing only)

• User level can override the institution ability
• Can be enabled when institution ability is disabled
• Can be disabled when institution ability is enabled

Example scenario where FI wants to test a new feature during beta or otherwise:

• Banno employee enables user ability for select users, overriding the institution ability
• Institution ability is disabled
• User ability is enabled

Entitlements

Not to be confused with the People > Config > Entitlements app location above, entitlements typically refer to feature-specific flags or limits. User management is a great example of this. While there are top-level Abilities controlling access to various features, there are also provider entitlements (coming from AMS for CUs and BSL/NT for banks) that control access to various pieces of functionality or limits. Here’s an example related to ACH. In order for a user to have access to initiate an ACH batch, the following need to be enabled in Banno:

• ACH institution ability (People > Config > Entitlements)
• ACH organization ability (People > Organization > Permissions)
• ACH user ability (People or Online > User management > Top-level ACH toggle)
• ACH limits and Initiate ACH provider entitlement (ACH companies are also in the mix for credit unions)

History events

The History service contains events for both Banno People > User/Org > Activity and the Banno Activity application

• User/Org > Activity: Anything done that affects the user or organization. The user may have done it themselves, or an FI user may have.
• Banno Activity: Tracks actions taken by FI users, either impacting an account holder or another FI user, or even more broad sweeping actions, not affecting any one user.

This documentation will help you define what is needed for new events.

Mixpanel analytics

For each new page that is added to the Online and Mobile clients, a pageView event should be added and sent to Mixpanel. Please see the ops doc for full details about every property and event. As soon as the project has designs, the PM should update the Mixpanel Data Index with the pageId and the corresponding details in the sheet. For each new page being tracked, the PM should discuss with the client teams to determine the pageIds they would like to use.

Online captures pageView events automatically; no additional work is needed.

Mobile tracks every pageView event manually. The teams will need the following information to properly implement new events:

• Values of the new pageIds per event
  • Once designs are ready, the PM and client teams should meet and identify all the screens that need to be tracked and agree on unique pageIds for them.
  • For projects where Online work was completed before mobile, the Mixpanel Data Index should be referenced to find the existing pageIds to use
  • Example: ACCOUNT_ALERT_PREFERENCES - This is the id for the alerts preferences page from the account details.
• Which screens should be tracked?
  • Once designs have been created, each new pageView event should be mapped to an individual screen in the designs and provided to the mobile teams
• Additional event properties or user properties
  • At this time additional properties for an individual event are not possible. Additional properties can only be added to all events
  • User properties are details about the user that get captured when the user authenticates.
  • New event and user properties may be able to be added but should be discussed with the mobile teams to ensure that they can be added efficiently.

Example Content: We will be tracking one new event on the mobile clients only. We will capture when Zelle is launched so that we can get an accurate picture of Zelle usage across clients.

• Proposed pageId: ZELLE_LAUNCH
• This event should fire as soon as Zelle is launched.
• No additional user or event properties will be needed

String management

Details about string management.

Monthly meetup deck edits

Each month, we host a Monthly Meetup, where our leaders talk to customers and prospects about strategy, key updates, we do demos, and present our roadmap in a visual and engaging way. This is done using our Primary Meetup Deck. We should update it monthly in cadence with the meetup, so content is fresh and updated.

• All images should be pulled from Figma design spec so they all have the same JH theme and approved avatars/names
  • You can select a Frame, then export to PNG from right sidebar
  • Add to Slides, crop, round corners, and add drop shadow:
  • (ADD IMAGES)
• We should continue to update slides with additional information as we have it each month
  • Initial announcement might not have artwork, but after a couple months it might
• Process should be to do the following no later than the week before each meetup:
  • Review “last six months” slide and update as needed Primary Meetup Deck
  • Review roadmap slides
    • Links:
      • Consumer: Primary Meetup Deck
      • Admin: Primary Meetup Deck
    • Remove shipped things (make sure they’re added to “last six months”)
    • Move things over from Planned to Building, etc.
  • Update project slides
    • Add imagery
    • Update content
    • Update chips (targeted quarter, bank vs CU, business, etc)

Idealab

Idealab is the Jack Henry idea management platform. All Jack Henry customers have access to Idealab and this is the destination when they have an idea they would like to see within Jack Henry products.

As a Product Manager at Banno, you can access and moderate it using your jhacorp.com email address. You should only have access to the Banno section of Idealab.

As moderators within IdeaLab, it’s our job to:

• Apply knowledge from our domains
• Review incoming ideas for clarity
• Review trending ideas
• Communicate with the community about ideas submitted
• Provide details on already existing ideas
• Move new/vetted ideas to your Insights initiatives within Jira
• Keep ideas moving

In IdeaLab, the life of an idea starts with the customer submitting an idea. The idea sits in a queue for approval. It’s our job to make sure that we move ideas out of the queue and into the community. Once it has been approved, it is open to the community to vote up or down depending on how good of an idea it is.

Ideas are organized in stages and manually moved to new stages by us:

• Collaborate (recently submitted)
• Research (Has 15 or more votes) - Anything within the research phase merits a response from a PM on next steps or opportunities.
• Under consideration - An idea that has passed the research phase and added to your Insights Jira board.
• Roadmap - An idea that made its way to the roadmap
• Development complete - An idea that has been shipped, or is a duplicate of an existing feature.

Monthly release notes

Banno publishes monthly release notes to the For Clients Portal prior to shipping each mobile release. These are visual notes designed in Sketch. The product team is responsible for building these notes.

• The notes are created as a Google doc within our release notes folder on drive
• Create a new document from the release notes template and enter update the notes sections for this release. I usually start with Android, followed by iOS, followed by the Platform
• Make note of the estimated upload date for apps - you can get this from mobile teams in #org-mobile-deployment
• Write note entries that are appropriate for FI consumption these are not technical release notes
• Entries should be written in the past tense and have a human feel to them.
• Channel entries are brief and assume a subject of “We…” beginning with the verb: added, fixed, updated, etc
• Not every ticket will be included in the channel notes, some tickets may be combined into a single note item, some may get grouped into the generic bug fixes line at the bottom of each channel

Store notes These will most likely be the simple generic, bug fixes and performance improvements. Only features that are enabled by default and ship to every institution can be in the app store notes.

New features These are new feature descriptions written with the Banno voice. They may be based on the information included within the Banno Statement. An item is considered a new feature if it is available in every possible channel. If functionality is shipping in one channel but not others at the same time it should be described in the channel notes.

Android

• Android releases
• Select the release desired for notes and review the tickets within this release
• Pay attention to ticket type and status as writing

iOS

• iOS releases
• Select the release desired for notes and review the tickets within this release
• Pay attention to ticket type and status as writing

Platform-UX

• Platform UX release
• Note the first Platform release included in these notes (open the previous release notes file and use the second release number +1)
• Enter the two release numbers in the notes the first - last (the most recent release included)
• Begin with the oldest release and work your way forward reviewing the PRs included in each release and adding them to the appropriate Platform App

Completing the notes

• When the draft is complete and ready for review, post a link in these two Slack channels and request a :thumbsup: from managers:

  • #org-mobile-deployment: @pm, @janene, @mmunhall, and @dan
  • #org-customer-communication: @abby wood, @sheena, and @derek

• When you have approval tag @chris with a link to the doc to create the visual

• Chris will post the visual back for review - check it out, if it’s good tell him to post it