I see two questions baked in here: How do we improve team productivity? and How can we help a team be profitable?
This is a massive topic, so I'll only touch on it enough to explain why productivity is not the same thing as profitability. For a simple example, if I make widgets I sell for $10 and it costs me $100/day to operate, I need to make more than 10. Let's say I make 8. I can solve this by finding a way to make to, or by charging $13 instead. Both of these options make me profitable.
Changing productivity is a long-term investment. The 100% increase in productivity you've seen in such a short time is practically unheard of. I'm delighted for you and your team that you saw it, but it's not the norm and I wouldn't bank on seeing another turnaround like that. If you need a short-term fix, you need to be generating more value, which might mean charging more or prioritizing more valuable work.
I'd look at what kinds of improvements are coming out of your retrospectives. This is your primary vehicle for team improvement. Take a look at https://plans-for-retrospectives.com/en/ for ideas on more effective retrospectives. Try their more structured 5-stage approach to see if it generates more powerful insights. I don't know your team, but most teams I've worked with do not get full value from their retros.
Lean Wastes (3 M's)
There's a great exercise I've done with teams around the 3 M's in lean (Mura, Muda, Muri). Create 3 columns or sections on a board and explain the 3M's (quick description below) and ask them to write down sticky notes with wastes they encounter in their work day and put them in the right column. I usually get at least 20 - 30 out of a group. You can't solve them all at once and many can only be improved instead of removed, but this will give you a great list of things that slow your team down that you may be able to help with.
Couldn't find a link with descriptions I was happy with, so here are brief definitions:
Muri (Overburden): There is a maximum amount of work I can handle at once and after that, I just get bogged down in managing and prioritizing the work and it takes away from my time actually doing it. For more information and math proofs, take a look at Little's Law from queuing theory. Hint: the number of things is usually less than 5, in some cases, it's 1.
Mura (Variation): In knowledge work I see three common types of Mura waste. Context switching where I'm trying to multitask or split time on different projects. Task type variation that requires me to work in very different ways (grouping tasks types together can help with this). And finally, flow variation - for example, all stories moving to testing at the end of a sprint and the testers go from bored to overloaded.
Muda (Non-value-add activities): This is sort of self-explanatory. What activities take up time in the day that don't move your application features forward. You can also take a look at the lean 7 wastes for more on this, though it's mostly written from the manufacturing perspective and you need to do a bit of translation to knowledge work. (for example, items sitting in inventory translate to unreleased code)