Kanban to catch a quick-moving situation
We are a product development shop - and in fact we build a Kanban tool (SwiftKanban), in addition to others.  We have a lot of experience with Kanban and DevOps and separate boards for epic/ story detailing vs. dev/ ps tracking. Our DevOps setup is still being fully automated and being gradually fleshed out. We've been on this journey since 2010-11 - and we have achieved significant business benefits exactly of the kind you are looking for.

We started with a single Kanban board, but with 2 separate swim lanes for the product manager and the dev team - see below - 

Planning Lane for the Product Owner


Dev Lane for the main dev activity


Since we had a single team doing development as well as maintenance/ customer related work, as also refactoring work, we also had a few other lanes to help them visualize their overall workload - 


Over the last 6 years, we have evolved, as have our dev/ engineering practices.  While we never used Scrum - and don't have sprints, we do production releases every 4-6 weeks, we deploy to an internal staging server (which we use as our internal production server, where we use our product for dev as well as other functions such as marketing, sales, support, implementation services, etc.) every week or less, and we have a single workflow between Dev and Ops as you will see below.

From that separate planning lane, we have evolved to a full upstream Kanban board - which is our roadmap planning board, where we track Themes, Epics and Stories - and lay out stories in up to 4 releases out. We did this as we gradually figured out just how much work needs to get done to identify and detail the work to be done as well as to get stakeholder alignment so everyone agrees that we are working on the right stuff.

Roadmap Planning Board


Stories from this board get pulled to the Dev board.  Internal and customer reported defects are directly added to this board's Ready queue.  

Dev Board


As you can tell, the Product Owner (Product Manager) is responsible for the Roadmap board, while the Sr. Dev Manager is responsible for the Dev Board.  While Dev team members deply to Staging server, the Ops team ensures they have the right CI/ CD environment to do that.  After Dev/ Validation, it is the Ops Team's job to  deploy to production once sufficient valuable work has been completed (typically 4-6 weeks).

Both boards are accessible to all senior stakeholders as well as CEO, Sales and Marketing so everyone can track what is going on and what is prioritized for upcoming releases.

At the same time, we ensure we follow some of the recommended Kanban cadences, including the Daily Standup Meeting, the Weekly Replenishment Meeting (where fine-tuning of the story/ defect prioritization takes place) as well as Release Retrospective and a Quarterly Strategy Review Meeting.

The Kanban boards and cadences ensure that everyone is aware and aligned; and if there are conflicts, they are resolved during one of these meetings (other than the Daily Standup).

Besides key Kanban practices - including a reasonably strict adherence to WIP Limits - we have also, of course, invested heavily in engineering practices to enable a true continuous delivery/ deployment environment - and that journey still continues.  We are a Test Driven Dev shop and developers are responsible for JUnits, Functional Automation, and Peer Review.  Our code repository is Subversion and integration/ deployment is orchestrated using Jenkins. Subversion is integrated with our Kanban tool so all work at each stage is also updated on the card as well (via comments on the card). 

Overall, to answer some of your questions more specifically, 


Yes, it makes a lot of sense to provide a separate board to the product owner and another to the dev/ ops teams and link cards across them as needed.  
And it makes sense to organize the board by tasks/ workflow stages rather than people as that gives you greater flexibility with using cross-functional folks in different stages of the workflow.  
Most importantly, it lets you easily visualize and measure which workflow stages might be bottlenecks (rather than which people - which would typically be inaccurate) and what tweaks you might need to make to improve your flow and throughput and reduce lead time.


All the best with your transition to Kanban! If you need any more help with respect to Kanban, I strongly recommend reading David Anderson's book on the Kanban Method as well as refer to our comprehensive Kanban guide.

Hope this helps.