The workflow and status module in Aha Roadmaps allows the execution of a linear workflow. This idea suggests that even the variable workflow is too rigid and prevents representation of status in very impactful ways.
For example: for simplicity, let's say the workflow is
1) Under consideration
2) requirements development
3) UX design, Eng design
4) estimation
5) development
6) deployment
The "status" in Aha indicates that a feature (or other represented body of work) is current at a particular step. But those steps are actually bodies of work executed over a period of time and with their own status--each step can be not started, in progress, completed, waived, blocked.
It is VERY common to have multiple steps in progress at the same time. Here's the most common:
Product Manager is developing requirements in a PRD
Once a certain portion of the PRD is complete, the UX team can know enough to begin their work--but work on the PRD continues
Engineering can also start their work before the PRD is done, and before UX is done
The project managers/scrum masters can start their work before any of those are done
So in this case, you have 4 steps in the process all "in progress". But Aha forces us to say that it's at a single step, which falsely reports that prior steps are done. This is not an edge case. This is almost all cases.
This limitation is extremely impactful and hampers the users ability to get actionable visibility.
We do quarterly planning, and have 4 checkpoints per quarter over 60 days before engineering is authorized to do substantial work, commit a timeline, engage go-to-market teams, etc. At each of those meetings, the group leader's job is to assess the progress, naturally. Aha's current interface does not allow the leader to see where the bottlenecks are, because it is showing that the "status" is "estimation", when in reality, the PRD is not complete enough for the UX and Eng designers to do their work. But it's common practice to change the status once a step is started--especially because completion often happens downstream.
This is idea creates the ability to more accurately reflect status of each step. Each of the steps in the workflow should have a status selector--I suggest the default selections be not started, in progress, complete, waived, or blocked--with user having the ability to edit the list. Without this, the only true status tracking comes from Jira or Gitlab tickets receive progress reports. Since Development generally represents 1/4 or less of the overall LOE and calendar time, this is wholly unrepresentative of true status. Managers, designers, architects, planners, and others all contribute LOE and calendar time.
This complicates the Kanban board because a card can only be in one column. I suppose you could have the user choose whether it shows in the first-in-series incomplete column, or the last.