This blog post was co-written and edited by Matt Gritter.

The z/TPF lab thrives on the input of its users. Because we align product development with user needs and goals, we offer a number of ways to submit feedback and flag opportunities for improvement. The IBM Ideas Portal is key in this process.

If you've never submitted an idea before, here's how it works: when using the product, your team might begin thinking of ways it could be improved or augmented to fit current needs or emerging use cases ("Wouldn't be it great if this software had that capability?"). When you've developed a clear sense for your idea, how urgently it's needed, and how it could be implemented in your team, submit it through the IBM Ideas Portal request form. After it is submitted, the request is available for review by the product team, and also available for the rest of the IBM Ideas Portal Community to view, vote upon, and add context.

Based on the context provided in the request, its urgency, and its technical feasibility, the product team will determine whether to include it in their development roadmap. It's critical that other IBM Ideas Portal Community members vote and interact with submissions made by other users to ensure that high-priority items are given proper attention.

To help the product team understand your request, and to enable other users to align with, or add to, your idea, here are a few recommendations for writing clear, actionable ideas.

Writing the description

Describe the problem that needs to be solved in extensive detail. This is the most important aspect of any idea; it allows us to understand the user and how they are affected. It also gives us greater context around use cases, systems, and components affected by the issue, and any other circumstances that surround the situation where this problem arises.

Consider including a user story statement to help convey the problem and the value to be found in solving it: A <role> can <what>, so that <benefit>.

For example: "An application developer can measure and analyze resource usage of application changes so that we can minimize the system resource usage as the application changes over time."

You might follow this up with a more extensive description, walking through further context and illustrating the need for the enhancement.

"Our application developers largely modify existing applications. Over time, applications use more and more system resources that might have a variety of impacts, such as  requiring additional hardware, impacting system performance, and so on.

Our developers are unable to see the impacts of their code changes as they are making their updates during development. Often, large impacts are found by QA during performance testing. This is very late in the process, making resolution much more expensive and time-consuming. Ideally, we want to have developers perform ongoing tests and comparisons to baselines so that they understand and can mitigate the impacts of their changes as needed. This will reduce time spent reworking code by identifying problems sooner rather than catching resource usage issues during QA performance tests."

Then describe acceptance criteria for any given solution. This could include the expected inputs, outputs, or behavior. What criteria must be met for any solution to be acceptable? 

Consider using a <given>, <when>, <then> statement to describe the desired behavior.

For example: "Given that an application developer makes a code update to an existing application when they test the updated application's resource usage, then they can compare the resources used by the application to a baseline (prior to their code changes) and see changes in the CPU usage, ECB Existence time, FINDs, and FILEs for the application."

Finally, if you have a specific, proposed solution, write it last in the description:

For example: "Re-invent the performance analyzer in TPF Toolkit with comparison tables and such."

Writing the use case

Now that the problem has been fully detailed and contextualized, you can include your ideas for the features of any acceptable solution.

To follow on the example we've been building, you might include notes like this:

• The solution should facilitate the collection of a baseline and modified application runs.
• The solution should allow for comparisons between the runs.
• The solution should allow for analysis of the most heavily used functions by time, FINDs, FILEs, and number of calls.

Writing the business justification

Now, describe why the problem should be solved, including information such as the value or benefit felt by your business, customers, staff, or other key stakeholders. 

You should also note any hard deadlines and what they are driven by, such as legal requirements, security audits, or business mandates. If necessary, clearly state the dates requires for deliverables, betas for testing, or other key outcomes.

For example, you might write: "By leveraging a performance analyzer during application development we can minimize the system resource usage as the application changes over time and save time/money by finding performance issues earlier in the development process."

With regard to a deadline, you might also write: "We have a mandate from our business that this form of measurement must be in place by EOY 2020. As such, we need to start beta testing in August 2020 with delivery by the end of November 2020 to meet our mandate."

What if my idea isn't approved?

Of course, there's always a possibility that your idea won't get put on the schedule as a project. This could happen for a number of reasons: perhaps another user has submitted a similar request, or it's a known defect. It's also possible that the request you've submitted is actually related to open source software that's beyond the purview of the product team.

If the issue is that we don't have enough information based on what you've written, you can expect an email requesting further detail. In that case, consider revisiting some of the recommendations we've made in this blog post, or including attachments such as screenshots or diagrams to help illustrate the problem.

On the flip side, if your idea is approved, it's always valuable to have the input of users throughout the project lifecycle. Consider signing up as a Sponsor User so that your feedback is heard along the development process, and so you're first to learn when prototypes or beta testing is made available.